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(57) Abstract: A service discovery mechanism may 
allow clients in a distributed computing environment 
to search for services. The service discovery mecha- 
nism may allow a client to request a capability credent 
tial from a service. In one embodiment, the client may 
present to the service a set of desired capabilitiies. The 
service may then respond with a capability credential 
that may convey to the client the rights to use the re- 
quested capabilities. A complete service advertisement 
may be needed to create a message endpoiht for access- 
. ing the service. In an embodiment, the capability cre- 
dential may be used by a client to obtain a complete ad- 
vertisement for the requested capabilities. The capabil- 
ity credential may provide an additional level of secu- 
rity for the service provider. The capability credential 
that may be used to receive the complete advertisement 
may also be used to construct a message gate to com- 
municate with the service where the gate embeds the 
capability credential in each message to the service. 
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1. Field of the Invention 

This inventioa relates to distributed computing environments including Web-centric and Internet-centric 
distributed computing environments, and more particulariy to a heterogeneous distributed computing environment 
based upon a message passing model for connecting network cUents and services, and the discovery of services in 
10 such an wivironment 

2. Description of tiie Related Art 

Intelligent devices are becoming increasingly common. Such devices range from smart ^pliances, 
personal digital assistants (PDAs), ceil phones, lap top computers, d^op computers, workstations, mainframes; 
15 even, super computers. Networks are also becoming an increasingly common way to interconnw:t inteUigent 
devices so that they mdV communicate widi one another. However, there'may be large differences in the computing 
power and storage capabilities ofvariousinteUigent devices. Devices with more limited c^abilities may be referred 
to as small footpribat devices or "diin'' devices. Thin devices may not be able to participate in networks 
interconnecting more capable devices. However, it may stiU be desirable to mterconnect a wide variety of diff^ 

20 types of intelligent devices. 

The desire to improve networking c^abilities is ever increasing. Business networks are expanding to 

include direct interaction with suppliers and customers. Cellular phones, personal digital assistants and Internet- 
enabled computers are ; commonplace in both business and the home. Home networks are available for 
mt^nnecting audio/visual equipment such as televisions and stereo equipment to home computers, and other 
25 devices to control mtemgent systems such as security systems and tempera^ High bandwiddi 

mediums such as cable and ASDL enable improved services such as Internet access video on demand, e-cpmmerce, 
etc. Network systems are becoming pervasive. Even without a formal network, it is still desirable for intelligoit 
devices to be able to communicate with each o&er and share resources. 

Currently, traditional networks are complex to set xxp, expand and nwnage. For exanq>le, adding hardware 
30 or software to a network often requires a networic administrator to load drivers and configure systems. Makmg 
srnaU changes to a networic configuration may require that the entire networic be brought down for a period. In 
addition, certain intelligent devices may not support the necessary interfeces to communicate on a given network. 

What is needed is a simple way to connect various types of intelligent devices to allow for communication 
and sharing of resources whUe avoiding tiie interoperabiUty and complex configuration problems crasting in 
35 conventional networics. Various technologies exist for improvir^ tiie addition of devices to a network. For 
example, many modem I/O buses, such as the Universal Serial Bus, 1394 and PCI, support plug and pl^ or 
dynamic discovery protocols to sunplify the addition of a new device on Ihe bus. However, these solutions are 
limited to specific peripheral buses and are not suitable for general networks. 

A more recent techiiology, Jini fix)m Sun Microsystems, Inc., seeks to sin^ 
40 of devices such as printers and disk drives on a networic A device that incorporates Tmi may announce, itself to the 
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mAwoTk. may provide some details about its capabilities, and may immediate^ become accessible to otho- devices 
on the network. Jiai allows for distributed computing \^ere tbe capabilities of fee various devices are shared on a . 
network. The Jini technology seeks to enable users to share services and resources over a network. Another goal of 
toe Jim technology is to provide users with easy access to resources anywhere on the network vrhile allovong fte 
5 network location of the user to change, Jini also Seeks to simplify the task of building, maintaining and altering a 
rietvyork of devices, software and users. 

Jini requiies that each Jini aiabled device have a certain amount of nitanory and procesang power. 
. -Ilypicany,. a Jmi enabled device is equipped with a Java Virtual Machme (JVM). Hius, Jmi systons are Java; 
technology centered. Java is a Wgh level object oriented prbgramming Imguage developed by Sun Microsystei^ 
10 Inc. Java source code may be compiled into a format caUed bytecode, >Wch may &en be executed by a Java 
Virtual Machine. 

Bytecode is coii5)uter source code that is processed by a virtual machine, rather ftan the "real" cor^^ 
machine, the hardware processor. The vhlual machine converts graieralized machme instruction (flie bytecode) into 
specific machine instructions Onstructions lhat the computer's processor wiU understand). Usmg a language that 
15 comes with a virtual machme for each platform, the source language statements may be compaed only once and may 
then run on any platform that supports the virtual machine. The Java programining language is an example of such a 
language, and the Java Virtual Machine (JVM) is an example of a virtual machine platform ftat supports programs 

written in the Java iwogranaming language. 

Since Java Virtual Machines may be provided for most computing platforins, Java and feus Jmi ^ 

20 for a certain amount of platform independence. The Jini architecture leverages oS fee assumption feat fee Java 
programming language is fee hnplementation language for fee components of fee Jini system. The ability to 
dynamically download and run Java code is central to rnany features of fee Jmi architecture. 

Tlie puipcwe of fee Jioi architecture is to federate groiq)s of defaces and software conqionents into a smgle 
^amic distributed system. A key concept withm fee Tmi ardutecture is feat of a service. A service is an entity 

25 feat can be used by a person, a program, or anofeer service. Two examples of services are printmg a document and 
translating from one word processor format to anofeer. Jini allows fee members of a Jini system to share access to 
services. Services m a Tmi system communicate wife each ofeer by using a service protocol, which is a set of 
interfeces written m fee Java programming language. Services are found and resplved m a fmi system by a lopk-up 
service; A look-up service nwps mterfeces mdicating the functionality provided by a service to sets of obj^^ 

30 implement fee service. 

Descriptive entries may also be associated wife a service. Devices md ^pUcations use a process known as 
discovery to register wife fee Jini network. Once registered, fee device or appKcation places itself in fee look-^^) 
service. The look-up servic^ may store not onty pomters to feese services 911 fee network, but also may store fee 
code for accessmg feese serwc^. For example, when a printer registers wife fe(e look-rq) service, it loads its printer 
35 driver and/or an interface to fee driver into fee look-up service. When a cUent wants to use fee printer, fee drivCT 
and driver mterfece are downloaded from fee look-up service Ip fee client this code mobility means that cUents 
can take advantage of services from fee networkwifeoutpre-ihstalliDg or loatog drivers or othc^ 

a)mmunication between services in a Jini ^stem is accomplished using fee Java Remote Mefeod 
■ Invocation (RMI). RMI is a Java progrannning language enabled ertension to traditional remote probedure ca^ 
40 mechanisms. RMI allows not only data to be passed from object to object around fee Jmi network, but ftU objects 
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. including code as well. Jini systems depend upon this ability to move code around the network in a form that is 
encapsulated as a Java object 

Access to services in a Jini system is lease based. A lease is a grant of guaranteed access over a time. Each 
lease is negotiated between the user of the service and the provider of the service as part of the service protocol A 
5 service may be requested for some period and access may be granted for some period presumably considermg the 
. request period Leases must be renewed for a service to remain part of the Jini system. 

Figure 1 illustrates the basic Jini technology stack. The Jini technology defines a distributed programming 
model 12 (supported by JavaSpaces, leases, and object templates). Object communication in Jini is based on an 
RMI layer 14 over a TCP/IP capable networking layer 16. 
10 Jini is a promising technology for sunplifying distributed computing. However, for certam types of 

devices, Jini may not be appropriate, Ihe computing landscape is moving toward a distributed, Web-centric service 
and content model where the con^>osition of client services and content changes rapidly. The chent of the future 
may be a companion type device that users take with them A^erever they go. Such a device may be a combmation 
of a ceU phone and a PDA for example. It would be desirable for such devices to be able to communicate and share 
is resources with devices that are more powerful, as well as with thinner or less powerful devices. 

In addition, with flie advent of the Internet and resultuig explosion of devices connected to the net, a 
distributed programmmg model designed to leverage this phenomenon is needed. An enabling technology is needed 
feat facilitates clients connecting to services in a reliable and secure fashion. Various clients from thick to tiim and 
services need to be connected over the Internet, corporate Internets, or even witiiin smgle computers. It is desirable 
20 to abstract the distance, latency and implementation from both clients and services. 

The key chaUenge for distributed computing technology is to be scalable from powerful thick cUents down 
to very diin cUents such as embedded mobile devices. Current distributed computing technologies, such as Jmi, may 
not be scal^le enough for the needs of aU types of clients. Some devices, such as small foo^rint devices or 
embedded devices, may lack sufficient memory resources and/or lack sufficient networidng bandwidth to participate 
25 satisfactorily in current distributed computing technologies. The low end of tiie client spectrum, including 
embedded mobile devices, often have limited or fixed code execution environments. These devices also may have 
minimal or no persistent storage capabilities. Most small, embedded mobile devices do not support a Java Vhtual 
Machine. Most code-capable smaU cHents run native code only. In addition, most smaU devices have little more 
than flash memory or battery backed RAM as their sole persistent storage media. The si2» of the storage is often 
30 . very small and sometimes read-only in nature. Furthermore, the access time of tiiis type of storage media is often an 
order of niagnitude greater than hard didc access time in clients that are more pow 

Existing connection technologies, such as Jini, may not be as scalable as deshed because they are too big. 
For example, Jini requires that all participants support Java; however, many small clients may not have the resources 
for a Java Virtual Machine. Furthermore, due to its use of RMI, Jini requires that cHents be able to download code 
35 and content Jini may aiigment the existing client platform by downloading new classes, which may pose security 
and size concerns for small devices such as embedded devices. Jini works by cUents and resources communicating 
by passing code and data, men a ctient activates a Jini service, the service may retum its results to the ch^^ 
which may include a large amount of code or content In Jini, a cUeht m^ caU a method and a large object be 
returned, and thus downloaded. The cUent may not have the resource to accept die returned object In addition, 
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RMI and Java itself require a lot of memoiy. Many small foot print devices may not have, the resources to 
participate effectively or at aU in cun^nt distributed computing tecto 

Anotiier concern vwth existing distributed computing technologic 
connection capability and protocols. i?or example, Jini assumes tiie existence of a network of reasonable speed for 
5 connecting computers and devices. Jini also requires devices to support TCP/IP network transport protocoL 
However, many smaller devices may have limited connectioii capabilities. Small devices may have high latency or 
low speed network connections and may not support TCP/IP. 

As mentioned above, Jini requires devices to support Java and thus include a Java Virtual Machine, which . 
requires a certain amount of processing and stoirage capabilities that migbt not be present for many small devices. 
10 This ako restricts the flexibility of Jird in that non-Java devices may not dk Smce 
Jini requires Java, it may be deemed a homogenous environment However, it is desirable to have a distributed 
computing fecility for heterogeneous distributed computing that scales from extremely small embedded devices 
through PDA's and cell phones to laptops and beyond even to tiie most powerfiil computers. 

Other heterogeneous solutions exist, such as the Common Object Request Broker Architectmre (COKBA). 
15 CORBA is an architecture that enables program objects to communicate witii one another regardless of the 
programnung language they were written in or what operating system they're running on. However, CORBA does 
not address all of tiie connection issues tiiat are addressed by Jini. In addition, CORBA suffers from similar 
scalability problems as JinL 

Technology such as Jini and CORBA \ise a code-centric programmmg model to define the niterfece 
20 between remote components. A code-centric programming model defines programmatic interfeces or API's for 
communication between remote clients or components. The APFs may be defined in a particular programmmg 
language. The API's must be agreed to by all software componaats to ensure proper intax>perability. Since all 
access to componerits is through tiiese standards API's, the code tiiat itBplements tiiese API's must be present in the 
client platform. The code may be statically linked into the platform or cfynamically downloaded when needed. 
25 Many embedded or mobile devices simply cannot accept code dynamically from a network due to the quality control 
issues involved as well as the reliance on a single language and program execution environmenL Data-centric 
models, such as networking protocols, may avoid the dependence on moving code; howrever, such protocols are not 
rich enough to easily provide for distributed computing and tiiey also lack tiie ease of programming with code and 
other programmiiig features, such as type safety. 
30 Conventional distributed computing systems rely on the ability of a program executing on a first device to 

be able to remotely call a program on a second device and have tiie results returned to the first device. Tlie Reinote 
Procedure Call (RPC) is a basic mechanism for remotely calling a program or procedure, . CORBA and Jini are bolh 
based on tiie ability to remotely invoke program methods. However, communicating by passing code or objects, 
such as in Jini or CORBA, may be somewhat complex. For exan^le, as mentioned above, Jini uses the Java Remote 
35 Metiiod Invocation (RMI) to communicate between services. In order for a client to move Java objects to and from 
remote locations, some means of serialization/deserialization is needed. Such current fecilities in the Java 
Development Kit (JDK) rely upon the reflection API to determine the content of a Java object, and ultimately tiiat 
codemustconsulttiie Virtual Machine. This code is quite large and inefBcient ^ 

The fimdamental problems witii the cinrent method for domg serialization/deseriatizmion mclude its size, 
40 speed, and object traversal model. Code outside the JVM does not know tiie structure or graph of a Java object and 
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thus must traverse the object graph, pulling it apart, and ultimately must call upon the JVM, Traditional 
serialization and reflection mechanisms for storing and movmg Java objects are just not practical for all types of 
devices, especially thinner devices. Some of the difficulties with Java reflection and serialization are that an 
object's ^ph (ah object's transitive closure) reflection is difficult to do outside tiie JVM. Serialization is too large, 
5 requiring a large amount of code. In addition, serialization is a Java specific object interchange format and thus may 
not be used with nori- Java devices. 

The Jini distributed computing model requires the movement of Java objects between Java devices. Thus, 
the serialization mechanism itself is not platform independent smce it may not be used by non-Java platforms to. 
send and receive objects. Serialization is a homogenous object format - it only works on Java platforms, 
10 Serialization uses the reflection API and may be limited by security concerns, vMch often must be addressed usmg 
native JVM dependent methods. The reflection API m^ provide a graph of objects, but is inefficient due to the 
number of calls between the JVM and Ihe code calling the reflection methods. 

The use of leva reflection to serialize an object requires an application to ping pong in and out of the JVM 
to pick apart an object one field at a time as the transitive closure of the object is dynamically analyzed. 
15 Deserializmg an object using Java deserialization requires tiie application to work closely with the JVM to 
reconstitute the object one field at a time as the transitive closure of the object is dynamically analyzed. Thus, Java 
serialization/deserialization is slow and cumbersome vdiile also requiring large amounts of application and JVM 
code as well as persistent storage space. 

Even for thin clients tiiat do support Java, the Jini RMI may not be practical for thin clients with minimal 
20 memory footprints and minimal bandwidtL The serialization associated with the Jini RMI is slow, big, reqmres the 
JVM reflection API, and is a Java specific object representation. Java deserialization is also slow, big and requires 
a serialized-object parser. Even Java based thin clients may not be able to accept huge Java objects (along with 
needed classes) being retumed (necessarily) across the network to the client as required in Jini. A more scalable 
distributed computing mechanism is needed. It may be desirable for a more scalable distributed computing 
25 mechanism to address security concems and be expandable to allow for the passing of objects, such as Java objects, 
and even to allow for process migration from one network mode to another. 

Object based distributed computing systems need persistent storage. However, as discussed above, 
attempts at object storage are often language and operating system specific. In addition, tiiese object storage 
systems are too complicated to be used with many small, embedded systems. For example, die Jini technology uses 
30 JavaSpaces as persistent object containers. However, a JavaSpace can only store Java objects and cannot be 
implemented in smaU devices. Each object in a JavaSpace is serialized and p^ the above-described penalties 
associated widi Java serialization. It may be desirable to have a heterogeneous object repository for distributed 
computing that may scale jax)m small to large devices. 

JavaSpaces from Sun Microsystems, Inc., draws from the parallel processing work of David Gelemter, a 
35 computer science professor at Yale University. Gelemter's set of functions named "Linda" create a shared memory 
space called a TupleSpace, in which results of a computer's processes or the processes tiiemselves may be stored for 
access by multiple CPUs. Linda therefore provides a global shared memory for multiple processors. 

Another technology which extends Linda is TSpaces from IBM Corporation. TSpaces extends the basic 
Linda TupleSpace framework with real data management and the ability to download new dato types arid new 
40 semantic fimctionalityi TSpaces provides a set of network communication bufiers and a set of APIs for accessing 
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those buffers. Like many of the solutions discussed above, TSpaces therefore uses a code-centric prpgramming 
model and shares the drawbacks of such a model Additionally, TSpaces is implemented in the Java programming 
language and therefore requires a Java Virtual Machine or other means of executing Java bytecode, such as a Java- 
capable microprocessor. Therefore, TSpaces may be inappropriate for small-footprint devices which cannot devote 
5 sufficient resources for executing Java bytecode. 

It is desirable in object oriented distributed systems to be able to locate object repositories and find 
particular objects within those repositories. As mentioned above, the Tmi look-up server may not be practical for. 
small devices with small memory footprints. A more efficient mechanism for locating object stores may be 
desirable. 

10 It may be desirable in a distributed network computing model for clients to have die ability to locate 

services. Current network protocols either provide only a single standard service access mterfece that provides no 
security when accessing a network service or provides "aU or nothing** access to the full range of service's 
capabilities, which may include administrator or privileged functions. Also, current network protocols to locate 
services do not provide a flexible mechaiism for finding services. Current protocols eiAer do not provide any 

15 selective search capability at all (e.g. UPnP) or only provide a primitive keyword and attribute grammar mechanism 
(e.g. SLP). Thus, current service discovery mechanism may be too inflexible in their security and search criteria 
mechanisms. 

Also, current service discovery models have a symmetric model for service location. However, it may be a 
waste of resouorces for certain service devices, such as devices whose fimctionality is available on a proximity basis, 
20 to support the discovery model This is because such devices are aheady located by proximity (e.g. one device 
physically pointmg to another one). Thus, an alternate hght-weight discovery mechanism may also be desirable for 
such devices. 

Distributed object access also desires a fair and efficient sharing mechanism. As described above Jini 
curreritiy uses a leasing mechanism to sh^ objects. However, Jini leases are time based which may result in a 

25 number of problems. For example, the current object holder might have no idea how long to lease an object and 
rnay hold it top long. La addition, the use of time-based leases may require that tune be synchronized between 
multiple machines. Moreover time based leasmg may require operating system support In addition, Jini leases are 
established and released via RM. Thus, the Jini leasing mechanism suffers from the above-noted problems with 
using RML In addition, the Jini leasmg mechanism does not provide a security mechanism for establislung, 

30 renewing and cariceling of leases. Other leasing mechanisms may be desirable. 

Generally speaking, it is desirable for small memory foot print mobile client devices to be able to run a 
variety of services, both legacy and new, in a distributed environment The ^es of small clients in^ include cell 
phones and PDA's with a variety of difFeient networking interfeces, typically low bandvwdth. Often these devices 
have very small displays with limited graphics, but they could include laptops and notebook computers, which may 

35 have a larger display and more sophisticated graphics capabilities. The services may be a vwde range o/ applications 
as well as control programs for devices such as printers. It is desirable for a mobile client to be able to use these 
services \idierever they may be. 

A mobile client will often be at a temporary , dynamic network address, so networking messages it sends 
cannot be routed beyond that networking interfece (otherwise there may be collisions when two different cUcnts oh 

40 different networks have the same dynamic address). Mobile clients often do not have the capabiUty for a fiill 
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function Wer or other sophisticated software. . The displays may limit flie client from rummig certaia 
applications. Itaditionalapphcation models are based on predetennined user interface s data Any 
change to the application requires reccmpilation of the appllcatioa 

It may fee desirable for sudi cUents to have a mechanism for finding md mvoto^ 
5 or services. The client may need to run even large legacy applications which could not possibly fit in the client's 
memory footprint As discussed above, current technology, such as Jini, may not be practical for small footprint 
devices. The pervasiveness ofmobile thin clients may also raise additional needs. For example, it m^ be desirable 
to locate sendees based on the physical location ofthe user and his nwhaecUent For example, mformation about 
the services in a local vicinity may be very helpH such as.local restaurants. >yeather. traffic maps and movie 
10 mformation. Shnilarly, information about computing resources, such as printers in a particular location, may be 
helpfuL Current technologies do not provide m automatic mechanism for locatmg services based on physical 
location of the cUent Another need raised by thin mobile clients is that of address Thm 
mobfle clients typically do not contam ergonomic keyboards and monitors. The provision of such human factor 
ijCTvices and/or the ability to locate such services in a disb^uted compu^^ 
15 A distributed computing model should pit)videcUents with a my to find tnmsientdoo^^^ 

It may be desirable to have a mechanism for finding general-pmpose documents (including services and/or service 
. advertisements), where flie documents ai* expressed in a platform-indq«ndent and languag(^mdependent typmg 
such as thatprovided by eXtensiljle Markup Language CXML). Cunrent approad^^ 
for rmi, Umversal Plug and Play (UPnP). and the Service Location Protocol (^^^^ 
20 purpose document lookup mechanism. For example, the Jmi lookup mechanism is limited to Java Language typmg 
^ and is therefore not language-independent UPnP and SLP support a discovery protocol only for services, not for 
general-purpose documents. 

SUMMARY 

In a distributed computing enviromnent. a service discovery protocol may allow cUents to search for 
25 services (both space services and sjSecific services or types of services). Service providers (or alistener agent) may 
respond to search requests by publishing or providing correspondmg advertisements or UB^ 
advertisements, men a service provider responds to a discovery search request (either dired^ 
agent), the provider may choose to publish a protected or an ui^protected (complete) adv^ Aprotected 
adveriement may include the set of infimnation necessary to obtm a complrt^ Publishing a 

30 Fotected advertisement, forces the cUeiit to the obtam a valid credential from an authentication service before 
receiving the complete im-protected advertisement fi»m the service provider. A complete m-protccted 
advertisement is needed to create a gate, and therefore to use the service. Forcing cUents to obtain a valid credential 
beforcreceivinganadvertisementmayprovideanadditionallevelofsecurityforthes^^ Thesecmity 
credential that must be obtained to receive the complete advertisement may be the same security credential that is 
35 . used to construct a gate to communicate with the service where the gate embeds the security credential in each 
message to tiie service. 

To obtain a complete advertisement, given a protected advertisement, a client obtains a capabiUty 
credential from the specified authentication service by sending a credential requ^ The credential request 

message may be sent to an anthenticated service URI specified in the advertise 
40 to access. When the cUent's request is received, a capability credential is generated. Tbe capability credential m^ 
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be generated according to capabilities requested by the client and/or the client's level of mrfhorization: The cUent 
then receives the capability credential m response, to its request The response may contain the credential needed to 
generate the complete advertisement Ihis credential may be the same credential that the cUenfs gate includes in 
each message sent to the service, if the advertisement was a protected advertisement, the cUent then may send an 
5 advertisement request message contaming the capability credential and an identification (e.g. UUID) of the service 
to Ihe second XJRI specified in the protected advertisement The cUent then receives a complete advertisanent The 
response to tins second message is the complete advertisement of tiie specified service. The complete advertisement 
. and the capabiUty credential may flien be used to a^ate a gate used to conmiunicate wilh the sorvice. 

hi one embodfanent, a method for accessing a service in a distributed computing environment may inchide a 
10 ■ cUent locating a-fiist service within the distn^uted computing enviromnent. To locate ser^^ 

a search message in a data representational language, the search message may mclude search criteria, such as 
service name and service type criteria. Services or a listener agent receiving the search message may compare tiie 
search criteria to service advertisements to find advertisements that match the search criteria. Service 
advertisements may be data representational language docmnents that provide access information for correspondmg 
15 services. The cUent may tiien receive search response messages which mdicate advertisements tiiat matdied the 
search criteria. 

The client m^ then select a service that is desired to be accessed and request a c^ability credential to 

allow the cUent to access some or all of that services capabUities. The client may send a cq)ability credential 

request message to a URI specified in the selected service advertisement This URI may be for an authentication 

20 service. If the advertisement was a complete advertisement inchidmg schema infimnation formessages to access the 

service, then the client may receive a capabiUty credential for accessmg tiie services complete capabilities. If tiie 

advertilement was a protected advertisement which does not mclude access schema infomiation, tiien tiie cHent may 

include wittim its capability credential request message an mdication of a set of desired «5)abiHties for which it 

desires permission to access fi-om the service. 
25 A client tiien receives tiie capability credential wMch indicates tiiatfliecUent is allowed to access at least a 

portion oftiie services capabilities, ihe capabilities for whichtiiecUent is allowed access may be tiie lesser of tiie 

set of capabiUties which tiie client requested in its capability credential request message and the set of capabilities 

for which tiie cUent is auttiorized. If tiie original advertiseinent indicated m flie response to tiie cUents search 

message was not a complete advertisement tiie client tiien uses tiie capability credential to requKit a complete 

30 advertisement for its granted capabiHties. The cUent may send a advertisement reqiiest message to a URI specified 
in tiie protected advertisement A service provider receiving tiie advertisement request message may generate a 
custom complete advertisement for tiie capabiKties mdicated by tiie clients capability credential and return tiiis 
complete advertisement to the cUent . The cUent may ttien construct a message gate based on the complete 
advertisement for sendmg messages according to tiie schema in tiie complete advertisement to access tiic services 

35 capabUities. The gate may include tiie capabQity credential in each message so tiiat its messages may be 

aufliaiticated by the service. 

BRIEF DESCPn^ON OF T HE DRAWINGS 
Figure 1 is an illustration of a conventional distributed computing technology stack; 
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Figure 2 is an illustration of a . distributed computing environment programming model according to one 
embodiment; 

Figure 3 is an illustration of messaging and networking layers for a distributed computing environment 
according to one embodiment; 

5 Figure 4 is an illustration of a discovisry service for finding spaces advertising objects or services in a 

distributed computing environment according to one embodiment; 

Figure 5 illustrates client profiles supporting static and formatted messages for a distributed computing 
environment according to one embodiment; 

Figure 6 is an illustration of a distributed computing model employing XML messaging according to one 
10 embodiment; 

Figure 7 illustrates a platform independent distributing computing environment according to one 
embodiment; 

Figure 8 is an illustration of a distributed computing model in which services are advertised in spaces 
according to one embodiment; 

15 Figure 9 is an illustration of a distributed computing model in which results are stored in spaces according 

to one embodiment; 

Figure 10 is an illustration of client and service gates as messa^g endpoints in a distributed computing 
model according to one embodiment; 

Figure 10b is an illustration a message endpouit generation according to a schema for accessing a service 
20 according to one embodiment 

Figure 11a illustrates gate creation in a distributed computing environment according to one embodiment; 
Figure 1 lb illustrates gate creation and gate pairs in a distributed computing environment according to one 
embodiment; 

Figure 12 is an illustration of possible gate components in a distributed computing enmonment accordmg 
25 to one embodiment; 

Figure 13 is an illustration of proxy client for a conventional browser to particq>ate m the distributed 

computing environment according to one embodiment; 

Figure 14 iOustrates the use of a method gate to provide a remote method invocation intM^a 

in a distributed computing environment according to one embodiment; 

30 Figure 15 is an illustration of the use of a space in a distributed computing environment according to one 

embodiment; 

Figure 16 illustrates advertisement structure according to one embodiment; 

Figure 17 illustrates one example of advertisement state transitions that an advertisement may undergo 
during its lifetime according to one embodiment; 
35 Figure 18 is an illustration various space location, mechanisms in a distributed computing enviroimient 

according to one embodiment; 

Figure 19 is an illustration of space federations in a distributed computing environment according to one 
embodiment; 

Figure 20 is a flow diagram illustrating client formation of a session vwth a space service in a distributed 
40 computing environment aiccording to one embodiment; 

■ ' 9 
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Figure 21 is an iUustration of a space event type Werarchy for one embodim^ 

Figure 22 is a flow diagram illustrating service instantiation in a distributed computing environment 
according to one embodiment; 

Figure 23 is an illustration of a default space in a distributed computing environment according to one 

5 embodiment; 

Figure 24 illustrates an example of a device bridging proximity-based devices onto another transport 
mechanism to aUow the services provided by the proximity-based devices to be accessed by devices outside the 
proximity range of the devices, according to one embodiment; 

Figure 25 is an illustration of the use of lease renevral messages in a distributed computing environment 

10 according to one embodiment; 

Figure 26a is a flow diagram iDustrating an authentication service providing an auth^^ 

a client according to one embodiment; 

Figure 26b is a flow diagram expanding on step 1002 of Figure 26a and illustrating an authentication 
service generating an authentication credential according to one embodiment 
15 Figure 27 illustrates one embodiment of a bridging mechanism; 

Figure 28 illustrates an example of a space discovery protocol mapped to an external discovery service 

according to one embodiment; 

Figure 29 illustrates britfeing a client external to die distributed computing environment to a space m die 
distributed computing environment according to one embodiment; 
20 Figure 30 is an illustration ofa proxy mechanism according to one embodiment; 

Figure 3 1 iUustrates one embodunait ofa cUent with an associated display and display service accordmg to 
one embodiment; 

Figm-es 32A and 32B illustrate examples of using schemas of dynamic display objects according to one 
. embodiment; 

25 Figure 33 A illustrates a typicd string representation in the C programming lan^ 

Figure 33B iUustrates an exaiiq)le of a conventiorial string function; 

Figure 33C illustrates an efficient method for representing and managing strings m general, and in small 
footprint systems such as embedded systems in particular according to one enjbodiment; 

Figure 34 illustrates a process of moving objects between a client and a service according to one 
30 embodiment; 

Figures 35a and 35b are data flow diagrams illustrating embodiments where a v^ 
includes exterisions for compilmg objects (e.g. Java Objects) into XML representations of the objects, and for 
decompiling XML representations of(Java) objects into (Java) objects; . 

Figure . 36 illustrates a chent and a service accessing store mechanisrns in the distributed computing 
35 enviromneiit, according to one embodiment; 

Figure 37 illustrates process migration using an XML representation of the state of a process, accordmg to 

one embodiment; 

Figure 38 illustrates a mobile client device accessing spaces in a local distributed computing networic, 
accordingto one embodiment 



10 



wo 01/86394 



PCT/USOl/15134 



Figure 39a illustrates a user of a mobile device discovering the location of docking stations, according to 
one embodiment; 

Figure 39b illustrates a mobile client device connecting to a docking station, according to one embodiment; 

Figure 40a illustrates an embodiment of embedded devices controlled by a control system and accessible 
5 witidn the distribmed computing environment, according to one embbdm^ 

Figure 40b illustrates a device control system connected via a network (e.g. the Internet) to embedded 
devices accessible within the distributed computing environment, according to one embodiment; 

Figure 41 is a flow chart illustrating service discovery according to one embodiment; 

Figure 42 is a flow chart illustrating an example of locating service advertisements according to one 
10 embodiment 

Figure 43 is an Ulustration compares the difference in the discover process when the published 
advertisement is a complete advertisement versus aprotected advertisement, accordii^to 0 

Figure 44 is a block diagram of an example of a system m which a client device directiy discovers a service 
on a service device over a proximity Imk, according to one embodiment; and 
15 Figure 45 is a basic flow diagram illustrating cUent discovery of a proximity service, accordmg to one 

embodimetit 

While the invention is susceptible to vmious modifications and alternative forms, specific embodhnents 
thereof are shown by way of example in the drawings and will herein be described in detail. It should be 
understood, however, that the drawings and detailed description thereto are not intended to limit the invention to the 
20 particular form disclosed, but on the contrary, die intention is to cover all modifications, equivalents and alternatives 
felling within the spirit and scope of the present invention. 

PETAIUEP DESCRIPTION OF EMBODIMENTS O F THE INVENTION 

25 Ov^^ew of Embodiments for Distributed Computmg 

Turning now to Figure 2, a distributed computing environment programming model is illustrated. The 
model includes API layer 102 for faciHtating distributed computing. The API l^er 102 provides an interfece that 
facilitates cUents connecting to services. The API layer 102 is concerned with the c^covery of and the connecting 
of cUents and services. The API layer 102 provides send message and receive message capabilities. This messaging 
30 API may provide an mterface for simple messages in a representation data or meta-dak foraiat, such as in the 
extensible Mark-up Language (XML), Note that while embodiments are described herein employing XML, other 
metardata type languages or formats may be used in altemate embodiments. In some embodhnents, the API layer 
may also provide an mterface for messages to communicate between objects or pass objects, such as Java objects. 
APrs may be provided to discover an object repository or "space", find a particular object, claim and release an 
35 object, and write or take an object to or fi-om tiie object repository. Objects accessible through API layer 102 m^ 
be represented by a representation data format, such as XML. Thus, an XML representation of an object may be 
manipulated, as opposed to the object itself 

API layer 102 sits on top of a messagmg layer 104. The messagmg layer 104 is based on a representation 
data fonnat, such as XML. In one embodiment, XML messages are generated by messa^ layer 104 according to 
40 calls to the API layer 102. The messaging l^er 104 may provide defined static messages that may be sent between 
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cUents and services. Messaging layer 104 may also provide for dynamically generated messages:. In one 
embodiment, an object,.such.as a Java object, may be dynamically converted into an XML representation. TTie 
messaging 1^ 104 may tbrai send flie XML object representation as a message. Conversely, the me^aging layer 
104 receive an XML representation of an object The object may then be reconstituted 
5 . In one embodiment, messages sent by messa^g layer 104 may include several basic elements, such as an 

address, authentication credentiak. security tokens, and a message body. The miessage system transmission and 
receive mechaiusms m^ be completely stateless. Any notion of state m^ be embedded m the message stream 
between sender and recewer. Thus, masage transmission may be done asynchronously. In a prefeired 
embodiment, no connection model is imposed. TTius, transports such as TCP are not required. Also, eiror 
10 conditions may be limited to non-delivciy or security exceptions. 

Messaging layer 104 sits on top of a message capable networking l^er 106. In a preferred embodiment 
messaging l^er 104 does not requne that a particular networking i»otocol be used. TCP/IP and UDP/IP are 
examples of message Citable protocob that may be used for message capable networking layer However, 
other more specialized protocols such as the Wireless AppUcation Protocol (WAP) may also be used. Other 
15 possible message protocols are IrDA and Bhietooth networic drivers beneatii tiie transport l^er. Networking layer 
106 is not Ihnited to a smgle reUable connection protocol such as TCP/IP. Therefore, connection to a larger variety ^ 
of devices is possible. 

In one embodiment, message capable network layer 106 may be implemented from the networkmg classes 
provided by the Java2 Miao Edition (J2ME) platform. The Java2 Micro Edition platform may be suitable for 
20 smaller footprint devices tihat do not have the resources for a foil Java platform or in v«*ich it would not be efBdent 
to run a M Java platform. Since J2ME aheady provides a message capable femily of networking protocols (to 
support, sockets), it foUows that for the small footprint cost of adding messagmg layer 104, distributing computing 
fecilities may be provided &r small devices that ahready include J2ME. 

Message capable netwoikhig layer 106 may also be provided by the Java Development Kit's (JDIQ 
25 javajiet networking classes. Altemativefy, any message capable networking fecilities may be used for message 
capable networking layer 106. In a preferred embodiment, a reliable transport is not required. Hais embedded 
devices supporting an unreliable data gram transport such as UDP/IP may still siqiport the messa^g layer. 

Thus, flun clients m^ participate in a distributed computing environment by sinq)ly addmg a flim 
messaging layer 104 above a basic networking protocol stack. As shown in Figure 3, a basic system includes 
30 messaging layer 104 oil top of a networidng layer 106. The netwoikmg l^er may provide for reliable messages, 
e.g. TCPi or unreUable messages, e.g. UDP. The Memet Protocol (IP) is shown in F^Jre 3 as m exarnple of 
protocol &at may be used in networking layer 106. However, the distributed computing environment does not 
requite IP. Other protocols may be used m fee distributed computing envm>nment besides IP. A network driver 
such as for Ethernet, Token Ring, Bluetooth, etc. may also be part of flie networking layer. Many small cUents 
35 aheady provide a network driver and transport protocol such as UDP/IP. Thus, with the addition of the tiiin XML 
based messaging layer, flie device may participate in tiie distributed computing environment 

Thus, flie foundation for the distributed computing environment is a simple message passing layer 
implemented on top of reliable connection and/or unreUable data grams. The messagmg technology is very different 
' from commmiications technologies employed in other distribution computing systems, sudi as Jmi \^ch employs 
40 the Java remote mefliod invocation (RMI). The message passing layer .104 supports an asynchronous, stateless style 
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of distributed programming, instead of the ^chronous, state-fiiU style predicated by RML Moreover, message 
passing layer 104 is based on a data representation language such as XML and thus copies data, but not code; from . 
source to destination, unlike RMI. By using a representation data language, such as XML, messagmg l^er 104 may 
interoperate with non-Java and non-Jini platforms m a seamless feshion because Java code is not assumed on the 
5 sending or receiving end of a message. Moreover, unlike RM[, messaging layer 104 does not require a reliable 

transport mechanism such as TCP/IP. 

The message passing layer may provide simple sendQ and receiveO methods to send a message specified as 
an array or string of bytes, for example. The sendQ method may return immediately, performing &e data transfer 
asynchronously. For flow control purposes a callback method may be supplied which is invoked in the event that 
10 the sendO method throws an exception indicatmg it camiot handle the sendQ request The leceiveQ method m^ be 
synchronoiis and may return the next available message. 

The message passmg layer may also provide methods for stormg XML repr^ntations of objects^ services 
and content in "spaces'*. A space is named and accessed on the network using an URI (Uniform Resource 
Identifier). The UKL may be a URL (Uniform Resource Locator) or a sknpler version of a URL. In some 
15 embodnnents, the URL class may be too large. For such embodunents a simpler resource locator may be used that 
specifies the i^rotocol for moving the messages between client and server, protocol dependent host ID, protocol 
dependent port ID, and a space name. 

An XML representation of an object may be added to a space using a writeQ method provided by the 
messagmg layer. La one embodiment, the object and the cUent-specified name may be suppUed as. parameters. In 
20 6ne embodiment, the write method may translate the object mto its XML repress A takeQ method may be 
provided to return the object and remove it from the space. A findQ metiiod may be provided to return a specified 
object from its XML representation m a space. Hie findQ method may also be used to retum an array of matching 
objects in a space given a class. Each of these space methods is implemented using the message-passing layer. A 
lease mechanism may also be provided, as described in more detaU below. 
25 A discovery service may be provided for clients as a general search fecility that m^ be used by a client to 

locate a particular space. Rather than attempt to define a complicated search protocol which may not be feasible for 
a thin cUent to hnplement, the discovery service may ofQoad the actual search to XML-based search fecilities, 
leaving the discovery service sunply to provide interfece functionality to the client The approach is illustrated m 
Figure 4. In one embodmient, the discovery service receives a string specifying somethmg to locate, and it sends an 
30 XML message to a known discovery front-end (perhaps found in a defeult space), which then parses the string and 
makes a correspondrng XML query to a search fecili^ (which may be an internet search fecility). The discovery 
fronted may parse what it obtams from tiie search fricihty and repackage it as ah anray of strings (each string may 
be a URI for each found space) which it may send in an XML message to the client It should be noted that the 
discovery service does not require that the messagmg be atop a coniiection-oriented transport Thus, even very thin 
35 chents that do not have TCP could use such a discovery service. Hie discovery front-end makes it possible for the 
client to discover spaces without a browser or search fecility on the client The client only needs a simple fecility 
that sends a string that specifies keywords to the front-end, v\iiich interlaces with a search facility. 

A client inay be any platform that can send a message using at least a subset of the API and messaging 
layers. In one embodiment the API layer may provide for both static (or raw) and fonhatted (or cooked) messages. 
40 A server may be any platform capable of receiving and fulfilling mess^e requests. An explicit raw message send 
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may be provided that moves a series of bytes from a client to a semr or to aaother client The message type may be 
specified as reliable (e.g. TCP) or mireUable (e.g. UDP). The smaUest of devices may use raw unreUable message 
passing as their sole means of participation in the distributed computing environment Tlie device may use these 
messages to announce its presence and its status. Such small devices may also receive raw messages to implement 
5 certain fonctioiis, such as turning a feature on or off. 

Message-based services such as spaces may send and receive reliable formatted messages. A space 
message may be formatted with a well-defined header and with XML. In one embodiment, a formatted message 
send may occur when a client uses a space method to claim, write, or take objects from a space. The message 
contents may be dynamically formatted in XML and contam well-defined headers. Figure 5 illustrates client profiles 
10 supporting formatted and static messages. By using static messages, small devices may use a 

to participate in the distributed computing environment For example, a smaU device could just send basic . 
pre-defined messages. Depending on the client, the static pre-defined messages may consume a small amount of 
memory (e,g. <200 bytes). Static messages may also be an option even for larger devices. On the other hand, the 
dynamic XML messages may be useful when object values are not known at compile time. 
15 Turning now to Figure 6, a distributed computing model is illustrated that combines a messaging system 

with XML messages and XML object representation. The platform independence of XML may be leveraged so that 
the system may provide for a heterogeneous distributed computing environment Hius, cHent 110 may be 
implemented on ahnost any platform instead of a particular platform like Java, The messaging system may be 
implemented on any netwoik capable messa^g layer, such as Internet protocols (e.g. TCP/IP or UDP/IP). Thus, 
20 the computing environment may be distributed over the Internet In one eimbodiment, the messagmg system may 
also use shared memory as a quick interprocess message passing mechanism when the client and/or space server 
and/or service are on the same computer system. The distributed computing model of Figure 6 may also be very 
scalable because almost any size cheait can be configured to send and/or receive X^ 

As shown in Figure 6, two kinds of software programs may run in the distributed computmg model: 
25 services 1 12 and clients 1 10. Services 1 12 may advertise their capabilities to clients wishing to use the service. Hie 
services 1 12 may advertise tiieir capabilities in spaces 1 14. As illustrated in Figure 7, clients 1 10 and services 1 12 
may or may not reside withm tiie same network device. For example, devices 120 and 124 each support one client, 
whereas service 1 12a and client 1 10b are implemented in the same device 122. Also, as illustrated ui Figure 7, n 
particular platform is required for the devices to support die clients and services. For example, device 120 is Java 
30 based, whereas device 124 provides a native code runtime environment 

A device may be a networking transport addressable unit Example devices include, but by no means are 
limited to: PDAs, cellular/mobile phones, notebook computers, laptops, desktop computers, more powerful 
computer systems, even su5)ercomputers. Both clients and services may be URI-addressable instances of softwraire 
(or firmware) that run on devices. Using the distributed computing environment ardiitecture, a client may run a 
35 service. A space is a service that manages a repository of XML documents. Even though it is redundant, the tenn, 
^ace service, may be used herein, for readability. A software component may be both a client aind service at 
different times. For example, when a serrice uses a space (e.g. to advertise itself), that service is a cUe^^ 

space. . . 

Figure 8 illustrates the basic model of die distributed computing environment in one embodiment The 
40 distributed computing enviroronent may connect clients 110 to services 112 throughout a network. The network 
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may be a wide area network such as the Internet The netwoik may also be a combination of networics such as a 
local area network (LAN) connected to a wireless network ovct ttie Internet As shown in Figure 8, a service 112 
publishes an advertisement 132 for itself (represented in XML) in a space 114. The advertisement 132 specifies the 
servicers XML schema and URI address. Then, a cUent 110 may look up the advertisement 132. The client 110 
may use the advertisement 132 to instantiate a gate 130: The gate 130 allows die client 1 10 to run the service 1 12, 
by sendmg (and receiving) XML messages.to (and from) the service 1 12. 

Some results of runnmg a service may be returned to the client in an XML message. However, since other 
results may be too large for a small client to receive and consume at once, a service 1 12 may put those results or an 
XML representation of the results 134 m a space 114, as shown m Figure 9, and return them by reference (m an 
XML message) to the client 1 10, rather than by vahie. Exaniples of methods of retummg a reference to results 
mclude, but are not limited to: returning in the message a URI referencing the resufts in a space, and: returning m tfie 
message an XML document including the URI of the results. Later, the client 110 may access the results, or pass 
them by reference to anodier service. The space m which results may be stored may be different from the space in 
which the service is advertised. 

In one embodiment, the distributed computing envkonment uses XML for content definition, advertisement 
and description. New content for the distributed computmg environment (messages and advertisements for 
example) are defined in XML. Existing content types (e.g. developed for other environments) may also be 
described using XML as a level of indirection (meta-data). XML provides a powerful means of representing data 
tiiroughput a distributed system because, similar to the way that Jav^ provides universal code, XML provides 
universal data. XML is language agQOstic and is self-describmg. The XML content may be strpnigly ^ped and 
validated using schemas. Usmg a provided XML scheina, the system may ensure that only valid XML content is 
passed in a message. XML content may also be translated, into other content types such as HTML and WML. 
Thus, cHents that do not understand XML may still use the distributed computmg environment s^ces. 

In one embodiment, the distributed computing enviroimient messages may define the protocol used to 
connect clients with services, and to address content in spaces and stores. The use of messages to define a protocol 
allows many different kmds of devices to participate in the protocol Each device may be free to implement tiie 
protocol in a manner best suited to its abilities and role. For example, riot all devices are capable of supporting a 
Java runtime environment The distributed computing envhonmerit protocol definition does not require nor imply 
the use of Java on a device. Nor does it preclude it 

A service's capabilities may be expressed in terms of tlie messages the service accepts. A service's message 
set may be defined using an XML schema. An XML message, schema defines each message format using XML 
typed tags. Tlie tag usage rules may also be defined in the sdhema. The message schema may be a component of an 
XML advertisement along with the service's messiage endpoint used to receive messages. The distributed computing 
environment may allow chents to use all or some subset of a service's capabilities. Security policies may be 
employed to enforce the set of cq)abilities given to a client For example, once a set of capabilities ha? been given 
to a client, the client may not change that set without proper authorization. This model of capability definition 
allows for services levels that range fi*om a base set of capabilities to an extended set Extensions may be added to 
services by addmg to the number of recognized messages. 

In one embodiment, all operations in the distributed computmg environment are embodied as XML 
messages sent betwe^ clients and services. Storage (botii transient and persistent) providers are examples of 
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services lhat enable clients and services to store, advertise, and address content Clients and services may find each 
other and broker content using a transient storage space. Services may place a content or service advertisement in a . 
space. The advertisement may describe the content type or the capabilities of the service. Clients may subsequently 
browse spaces looking for advertisements that match a desired set of capabilities. When a client findis a matching 
advertisement, a communication channel may be established which may enable bi-directional message passing to the 
service backing the advertisement. In one embodiment, the communit^tion channel is authenticated. Results (which 
are just another content type) from service operations may be returned directly to the client in a response message, 
advertised and stored in a space, or advertised in a space, but stored persistently. Stored results ma^ be addressed 
using a URI (e.g. returned in the response message) and may have an associated authentication credential. 

Message Gates 

As discussed above, the distributed computing environment leverages off the use of a data description . 
language, such as XML. XML may be used to describe a target entity (e.g. document, service, or client) to an extent 
such that code may be generated to access that entity. The generated code for accessinig the target entity may be 
referred to as a message gate. Thus, in one embodirnent, the distributed computing environment differs £?om other 
distributed coinputing environments in that instead of passing the necessary code between objects necessary to 
access the other object, the environment provides access to XML descriptions of an object or target so that code 
may be generated based on the XML description to access the target The distributed computing envirocanent may 
use an XML schema to ensure type safety as well as a programming model (e.g. siq)ported messages) without having 
to agree upon language specific APIs, just XML schemas. 

Code generated from an XML schema may also incorporate the language, security, type safety, and 
execution enviroimient characteristics of the local platform. The local platform inay thus have control over the 
generated code to ensure that it is bug-free and produces only valid data according to the schema. Hie generated 
code m^ conform to the client's code execution environment (e.g. Java, C++, Smalltalk), as well as its management 
and security framework (Web-server and/or operating system). 

Note that the distibuted computing enviromnent does not require that code generated fix)m an XML 
schema be generated "on the fly" at runtime. Instead, some or all of the code may be pre-generated for categories 
(or classes) of services, and then linked-in during the platform build process. Pre-generation of code may be usefiil 
for some clients, such as embedded devices, where certain XML schemas are already known. In oiie embodiment, 
some or all of the code doesnt actually have to be generated at alL A private code-loading scheme (within the 
client) migjtit be used in one embodiment to augment the generation process. In addition, the distributed computing 
envirbimient may specify, in some embodiments, an interfece to download code for additional features in accessing 
a service (see, e.g., message conductors described below). T^ically, such downloaded code may be small and the 
client may have tiie option to download the code or not 

The phrase "generated code" may refer to code that originates within die client under tfie control of die 
client code execution environment, or to code that is generated elsewhere (such as on the service system or on a 
space service system) and that may be downloaded to tiie client systein after generatioiL Binding time, however, 
may be at runtime. At runtime, the generated code may be bound to a service address QMS), so that a message m^ 
be sent to tiiat service instance. 
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As discussed above, the interfece to any service in the distributed computing environment may be specified 
by an XML schema, defining the set of messages that a client may send (and receive from) that service. As 
illustrated in Figure 10, the client 1 10 and service 1 12 may each construct a message gate 130 for communicating 
according to the specified XML schema; From the XML schema advertised for the service 112 (and possibly other 

5 information m the service advertisement), a message gate 130a or 130b may be constructed by the client 110a or 
110b respectively. A corresponding message gate 1 30c generated from the same XML schema may also. exist on the 
service 112a. A gate 130 is a message endpoint that may send and/or receive type-safe XML messages, and that 
m^ verify the type correctness of XML messages when sending and/or receiving Ae messages. The message gate 
msy also provide for auflientication and/or other security mechanisms to ensure that the message endpoint is secure, . 

10 . In one embodiment, message gates are always secure. 

The distributed computing environment messagmg layer described above may be coupled to or may be part 
of tiie gate. The messaging layer asynchronously delivers an ordered sequence of bytes, using a netwoiidng 
transport, from the sender to the receiver, tnaintaining the notion on both the sender and receiver tiiat this sequence 
of bytes is one atomic unit, the message. The distributed computing environment does not assume that the 

15 networking transport is IP-based Instead, the messaging layer may sit atop v^^atever networidng transport 
supported by die device. 

Message gates may provide a mechanism to send and receive XML messages between clients and services. 
The XML messages may be **typed". For example, the messages may include tags to indicate if a message data field 
is, e.g., integer, floating point, text data, etc. A message gate may be constructed to verify the type correctness of 
20 messages sent or received. A message gate also may authenticate (e.g. securety identify) the sender of a received 
message. An XML schema may be provided for a service that describes the set of messages accepted by the service 
. and/or sent by the service, A message gate may verify the correctness of messages sent or received according to the 
XML scheina for \^ich the gate is constructed. 

A gate may be constracted as a single atomic imit of code and data that performs type verification arid/or 
25 message correctness verification and/or sender identification for messages between a client and a service in the 
distributed computing environment In one embodiment, once the atomic un& of code and data for a message gate 
has been created, it caimot be altered as to its typing, message descriptors, and sender identificatiorL In another 
embodiment, the gate may be modified as to the contents of tiie message schema after the gate is created, includmg 
deleting^ adding, or modifying messages in tiie message schema. 
30 A message gate is the message endpoint for a client or service in the distributed computing environment A 

message gate may provide a secure message eindpoint that sends and receives type-safe XML messages;. Messages 
gates may allow clients and services to exchange XML messages ui a secure and reliable feshion over any suitable 
message transport (e.g. HTTP). For a client, a message gate may represent the authority to use some or all of a 
service's capabilities. Each capabihfy niay be expressed in terms of a message that ni^ be sent to a service. Each 
35 such message may be sent through a client message gate which may verify the correctness of the message. The 
message m^ be received by a service message gate which may authenticate the message and verify its correctness. 

A message gate may provide a secure communication endpoint that type checks XML messages. As 
further discussed below, a message gate may also provide a inechanism to restrict the message flow between clients 
and services. In one embodiment v^en a client desires to access a service, a clierit and service message gate pair iia 
40 aeated, if not akeady existing. In one embodiment, the service message gate may be created when ^e service 
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receives a first message fix}m tiie clieat message gate. la one embodiment, one or more service m^sage gates may 
be created when, the service is initialized, and may be used to pair with client message gates when created The 
creation of a message gate may involve an authentication service that may negotiate the desired level of security and 
the set of messages that may be passed between client and service. In one . embodiment, the authentication service 
5 may. accept a cUent ID token (also refored to as a cUent token), a service ID token (also referred to as a service 
token), and a data representation language message schema that describes the set of data representation language 
messages that may be sent to or received from the service. For example, messages may be described that may be 
sent from a client to a service to invoke the service or to invoke aspects of the service. Messages may also be 
described that are to be sent from the service, such as response messages and event notification messages. Refer to 
10 the Authentication and Security section below for a further discussion of how the authentication service may be used 
in the construction and use of message gates. 

A client message gate and a service message gate pair may allow messages to be sent between the client 
and the service. In one embodiment, message gates may be created that only send and/or receive a subset of the 
total set of messages as described in the message schema for a service. This limited access may be used wilhm the 
15 distributed computing environment to implement a policy of least privilege whereby c to 

specific individual message types, based on a security poHcy. Refer to the Authentication and Security section 
bdow for a fiirther discussion of security checks for gate usa^ 

Client and service gates may perform the actual sendmg (and receiving) of the messages firom Ae client to 
the service, using the protocol specified in the service adverdsement (URI of service m the service advertisement). 
20 The client may run the service via this message passing. A message gate may provide a level of abstraction between 
a client and a service. A client may access a service object throu^ a message gate mstead of accessmg the service 
object directly. Since the gate abstracts the service fix)m the cUent, the service's code may not need to be to 
and then started, mitil the client first uses the service. 

The client gate may also perform verification of die message against the XML schema, or verification of 
25 die message agamst the XML schema may be performed by the service gate, e.g. if the cUent indicates it has not yet 
been verified. In some embodiments, verification miay not be practical for smiple clients and may thus not be 
required at tiie client In some embodiments, verification may be performed by the service. The gates may also 
perform authentication enablement and/or security schemes. In one embodiment, if a client does not si^port the 
protocol specified in the service advertisement, then it niay not be able to construct the rig^^ To avoid this 
30 problem, service advertisements (used for gate construction) may include a list of possible URIs for a service, so a 
variety of clients may be supported. 

A basic message gate may implement an API to send and receive messages. The API moves data (e.g. 
XML messages) m and out of die gate, validating messages before sending and/ or upon receiving. In one 
embodiment, message gates may support a fixed minimum API to send and receive messages. This API may be 
35 extended to other features as discussed below. As illustrated in Figure 10b, a gate 130 may be generated according 
to an XML schema 132, The generated gate code verifies messages based upon the XML schema. The gate 
verify correct message types and/or content tiirough the message APL As illustrated in Figure 10b, througji die 
message API a verified message may be sent to a service. The message may be received by a correspondmg gate at 
- the service. In response to die message, the service* may generate results 180. The service may return result data 
40 182 through its gate. The results data may be the results themselves or a reference to the results, such as a URI to 
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results stored in a space.. In various embodiments, the message API may support synchronous messages (request- 
response), asynchronous messages (response is disconnected Wreque^^^^^ 

cast messages (broadcast), and publish and subscribe (event messages), for example. Other type of messages may 

also be supported, such as remote method invocation messages. 

Each message sent by a gate may include an authentication credential so that the receiving gate may 

authenticate the message; Each message may also include a token which inchides infonnation aUowing the 

receiving gate to verify that the message has not been compromised or altered. For example, the sender may 

compute a hash or checksum of the message which may be verified by the receiver. The sender may also encrypt 

this token and/or the entire message using the sender's private key and may mclude in the encrypted message tiie 

• corresponding pubHc key so that the receiver may verify th^ the token was not changed- See the section below on 

Authentication and Security. 

A pair of message gates may provide a mechanism for conmunicating requests fix)mcta^ . 

response from services to cUents. Two associated message gate endpoints may be used to create a secure atomic bi- 
directional message channel for request-response message passing. Tlius, the distributed conq)Utmg environment 
5 may employ a message transport in which a message gate exists on both the ctient and to Thetwo 
gates may work togetiier to provide a secure and reliable message channel 

Turning now to Figure 11a, an Ulustration is provided for one embodiment showmg construction of a gate 
130a in a client 110 from a service advertisement or otiier service description 132. The cU^t may have a gate 
factory 140 that is trusted code on the client for generating gates based on XML service descriptions. The use of the 
20 gate fectoiy 140 may ensure that tiie gate it generates is also tnjsted code, and to^ 

the service advertisement As shown in Figure lib, agate 130c may also be constructed at a service 112. ThecUent 
gate 130a and the service gate 130c provide message endpoints for communications between the client and service. 
In one embodiment, the pieces the gate fectoiy needs to construct a gate 130 are tiie XML schema of tiie service 
(from tiie service advertisement) and tiie URI of tiie service (from tiie service advertisement). In anotiier 
25 embodhnent, an authentication credential may also be obtained and used in gate construction by rurming an 
authentication service specified in the service advertisement 

A gate fectory may provide a trusted mechanism to create message gates. In some embodiments, in order 
to ensure tiiat a message gate is a trusted message endpoint. tiie code used to create tiie gate must be trusted code. A 
gate fectory 140 may be a trusted package ofcodetiiat is used to create gates. In one embodiment, each client and 
30 service device platform tiiat desires to send and receive messages in tiie distributed computing environment may 
havea gatefectory. m some embodiments, gates may be pre-coiistructed by a separate gate 
witii pre-constructed gates may not need a full gate factory, or may include a partial gate fectory for binding a 
service URI and/or an autiientication credential to tiie pre-constructed gate at runtime (e.g. when messagmg is 
desired). 

35 A gate fectory for a device may generate gate code tiiat may incorporate tiie language, security, type safe^^ 

and/or execution environment characteristics of tiie local device platform. By constructing gates itself a device has 
tiie abiHty to ensure tiiat tiie generated gate code is bug-free, produces only valid data, and provides type-safety. An 
advantage of a device generating its own gate code as opposed to downloading code for accessing a service is tiiat 
' tiie cUent code management environment has tiie control The generated code may conform to tiie client's code 

40 execution environment (e.g. Java, C++, Smalltalk), as well as its management and security framework (Web-server 
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and/or operating system). Generated code is also trusted code, because the clienfs runtime environment was 
involved in its creation. Trusted security information therefore may also be added by the trusted generated code. 
Thiis, a device m^ receive an XML.message schema for a service and then construct a gate based on that schenaa to 
access the device. The XML schema may be viewed as defining the contract with the service and the generated gate 
5 code as providing a secure way to execute the contract Note that open devices, in which mi-trusted (e.g: 
downloaded) code may be run, may be configured so that gates may be generated only by trusted code. Open 
devices may employ a process model in which gates are enclosed in a protected, isolated code container that is not 
accessible to tools, such as debuggers, enable of discovering the gate's hnplementation, especially the gates 
authentication credential. 

10 A gate fectory 140 may negotiate on behalf of a chent with a service to create a gate to send messaged 

&e service. Similarly, a gate may be constructed at the service to receive messages firom the client gale and send 
messages to the client gate. Together, the client and service gates may fonn a secure bi-directional communication 
channeL 

A gate fectoiy may provide a level of abstraction in gate creation. For example, whon a client desires to 
15 use a service, instead of the cUent direct^ creating a gate to access ihe service, the gate may be created by a gate 
factory as part of instantiating the service. 

The gate fectory may create or may include its own trusted message gate that is used to communicate with 
an authentication service (e.g. specified by a service advertisement) to receive an authentication credential for the 
gate being constructed. For services that do not restrict access, a gate may be constructed without an authentication 
20 credential. The gates for such services may not need to send an authentication credential with each message since 
the service does not restrict access. The authentication service is an example of a s^vice tiiat does not restrict 
access, in one embodiment Thus, a gate factory may be configured to optimize gate construction by checkmg 
whether a service restricts access. If the service does not restrict access, then die gate factory may avoid running an 
authentication service as part of gate construction and may avoid included provisions for an authentication 
25 credential as part of ^e constructed gate. The gate factory may also receive or download an XML message schema 
(e.g. specified by a service advertisement) to create a gate matching tiiat sdiema. The gate factory may also 
receive or download a URI for the service and/or for a service mesisage gate for use m creating the client message 
gate to communicate with the URI. 

In addition, another gate construction optimization may be employed for certain clients tiiat do not desire to 
30 perform checking of messages agamst a service's XML schema. The client may be too tiiin to perform the checking 
or may rely on the service gate to perform the checkmg or may simply choose not to perform the checking (e.g. to 
reduce gate memory footprint). The gate fectory may be configured to receive an indication of whetiier or not a gate 
should be constructed to verify messages against die provided XML schema. In some embodiments, certain clients 
may have a gate fectory that does not provide for inessage verification against a schema for its constructed gates. In 
35 some embodiments, gates may be pre-constructed not to verify messages. In some embodiments, a gate may be 
constructed to verify oufeoing messages only, or verify received messages only. Thus, in some embodiments, a 
client may avoid or may chose to avoid building some or all of the gate code that checks die messages against the 
XML schema. * 

In some embodiments, devices may maintain a cache of gates to avoid constructing tiiem each time die 
40 same service is run. For example, when a new gate is constructed by a gate factory, the gate may be maintained in a 
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gate cache. When the gate is no longer being used, it is kept in the gate, cache instead of being deleted If the gate 
cache becomes full, one or more gates may be removed from the gate cache accordmg to a cache replacement 
algorithm, such as least recendy used. When the gate fectory is caUed to construct a gate, it first checks the gate 
cache to see if a matching gate aheady exists so that construction of a new gate may be avoided. 

The buildmg of a gate may be made lightweight by appropriate reuse of pieces used to construct other 
gates. Certain portions of each gate may be the same, and thus may be reused from gate to such as parts of the 
message verification code. Also, for some devices, common gate code may be built into the system software for die 
device and shared by all gates on that device. Thus, the gate fectoiy may avoid rebmlding this common code for 
each gate. Instead, the gate factory may simply bind the gate to this system software portion. For example, a system 
software portion may be provided to handle the message layer over wtotevea: transports are provided on tiie device. 

Space services in particular may be good candidates for rdany of the gate construction optimizations 
described above since a service gate constructed for a space service may perfonn many of the same functions as 
other service gates for that space service. Refer to the Spaces section below for more infonnation on space services. 

In some instances, a more efficient form of method invocation may exist For exan^)le, if the target service 
runs in the same Java Virtual Machine as tiie client application, a more efficient fonn of method mvocation may be 
to create a Java dynamic proxy class for the service. In such a case, a java:lang jeflectMethod invocation may be 
faster than sendmg a message. A gate binding time procedure may check for such an optimization and use it instead 
of running the gate fhctoiy to create a gate or bind an existing gate. 

In one embodunent, such as for special-purpose clients or small embedded devices, the generation of gate 
code at runtime may not be desirable due to memory consumption and code generation time, thus, instead of 
having a gate factory that generates gates at runtime, in some embodnnents gates may be pre-generated and buih 
into tiie device. For example, message gates may be generated during the bufld of embedded software as a means of 
inchidmg a built-in seone message endpoint that does not have to be constructed at runtime. Thus, a client with 
built-in gates may not need a fbU gate factory, or m^ require only a partial gate fectory for performing certain 
runtime binding to a built-m gate, such as for the URI and/or authentication credential. 

A generation tool may be provided for the pre-constniction of gates. The generation tool inay include an 
XML parser, a code generator and a code compiler. In one embodiment, the code generator may be a Java source 
code generator and the code compiler may be a Java code conq>iler. During the build of the software for which 
built-in message gates is desired, Ihe generation tool is run with iiyjut from all the relevant XML schemas for which 
gates are desired. 

As an exmnple, if it is desired for a device to have a, built-in message gate that can send and receive 
messages from a digital camera, the build of the device software may mclude running the gate generation tool vsdth 
the camera's XML message sdiema as input The XML schema may be parsed by the XML pars^ that m^ convert 
the XML schema mto an mtemal form suitable for quick access.during a message verification process. The tool's 
code generator may provide source code for a gate corresponding to the camera's schema. In some embodiments, 
the generation tool may also compile tiie source code and the gate code may be linked mto the software package for 
the device. At runtime, the camera service may be discovered m the distributed computing environment The 
message URI fdr tiie camera service may be bound to tiie built-in gate for the camera within ^e device. The bindmg 
of tiie URI to the pre-constracted gate may be performed by a gate constructor within the device. This gate 
constructor may be a much smaller, simpler gate fectory. When tiie camera service is instantiated, the URI for. tiie 
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camera service is passed to the gate constructor as an XML message. The gate constructor may then bind the URI to 
the pre-cbnstnicted gate. 

Hius, a gate may be partiaOy or fiiUy generated at runtime, or a gate may be pre-generated before runtime 
with a binding process (e.g. for a URI or credential) perfoimed at runtime. In one embodiment, a gate generation 
5 tool such as &e gate factory or the generation tool for pre-constructed gates may be a Java^based tool to provide 
some level of platform independence. Alternatively, gate generation tools may be provided in any language, such as 
the native code for a particular device in the distributed computing enviroM^ 

Note that the distributed computing environment does not prechide a device from downloading part or all 
of a gate's code. For example, in some embodiments, a service may provide gate code that may be downloaded by a 
10 cHeht wishing to access that service. However, downloaded 

A more detaUed illustration of possible gate components for one embodiment is shown m Figure 12. A 
gate may mchide its address (or name) 150, a destination gate address 15^ 

thereof) 154, and a transport URI 153. In o&er embodiments, a gate may also include an authenticatipn credential 
156. Some gates inay also include a lease 158 and/or a message conductor 160 to verify message ordering. 

15 Agate'sname 150 may be a unique ID that wiU (for the life of the gate) refer only to it Agatem^be 

addressed using its gate name 150. In one embodiment, gate names may be generated as a combination of a string 
from an XML schema (e.g. from a service advertisement) and a random number, such as a 128-bit random number. 
The name 150 may allow clients and services to migrate about the network and still work together. In a preferred 
embodiment, the gate address is independent ofthe physical message transport ad^ Thus, a 

20 gate name may provide a virtual message endpoint address &at may be bound and un-bound to a message trmsport 
addr^. In one embodiment, a gate's name may be a Universal Unique Identifier (UUm 
the gate, refer only to it 

A gate name may persist as long as the gate persists so that different applications and clients executing 
withm the same device may locate and use a particular gate repeatedly. For example, a gate may be created for a 

25 first client process executmg withm a device to access a service. After the first cHent process has completed its 
activity with the service, it may release the gate. Releasing the gate may involve un-binding the gate from tiie first 
client process's message transport addr^s (e.g. IP and/or Port address). The g^te may be stored in a gate cache or 
repository. A second client process executing within the same device that desires to run the same service may locate 
the gate by its name and use it to access the service. To use the gate, ^e second cUent process may bind the gate to 

30 . its message transport address, so that the message midpoint for the second cUent process is a combmation of the gate 
name and the second clirait process's transport address. In another example, a client may receive a dynamic IP 
address (e.g. a mobile cUent). When the client's transport address changes, a gate name (or gate names) may be re- 
bound to the client's new transport address so that the cUent may still access a service(s) that it previously accessed 
without havmg to relocate the service and recreate the gate. A gate name may also be usefiil for process migration. 

35 A process and my associated gates may be checkpointed or saved at one node in fte distaibufed computing 
environment and moved to another node. The process may be restarted at flie new node and the associated gates 
may be bound to the transport address for the new node so that the process will still have access to the external 
services to which it had access before being migrated, A gate may track the current location of another gate to 
viidch it is paired. Thus a service or client may be migrated and still be accessible. For example, replicated or Ipad- 

40 balanced service implementations may be abstracted from clients of the service by tiie gate. 
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Thus, a gate name 150 provides a flexible mechaiiism by which to address a message, endpoint m the 
distributed computing environment A gate name may be used to locate and/or address a gate over a wide range of 
networks, &om a local network to fte Internet Gate names m^ be independent of message transport so that a 
message endpoint (gate) may be moved from transport to transport by unbinding and rebinding to different 
5 imderlying transport addresses (e,g. IP/Port address pairs). 

In one embodnnent, a gate may also be separated from a service so that the same gate may be used, to send 
requests to different services oyer time. This may involve un-binding tiie gate's destination gate address 152 and 
binding a new destination gate address to the gate. 

A gate may be implemented as a layeir above a device's transport layer (e.g. networidng sockets). Each 
10 gate may include a transport reference 153. The gate name 150 may be bound to the transport reference 153 as 
described above. Multiple gates m^ share tiie same message transport For example, multiple gates may have 
transport references 153 to tiie same TCP/IP socket By sharing the same message transport, the size and 
complexity of each gate may be reduced A device in the distributed computing environment may have a laigje 
number of gates that need to send and receive messages. The message handling coiiq)lexity for multiple gates may 
15 be reduced by sharing a common message transport. The transport reference 153 m^ be a transport XJRI (e.g. 
URL) or sockk reference and may provide a mechanism for naming an underlying transport and sharing the 
transport with otiier gates. Multiple local gates may include a ref^ence 153 to tiie same transport, however, each 
local gate may behave independently of tiie otiier local gates sending and receiving messages to and from its paired 
remote gate. 

20 The schema 154 inay be downloaded from a space into the gate by the gate fectory. The schema may be 

compiled mto an internal form suitable for quick access during a message verification process. In one embodiment, 
the schema may specify two groups of messages: client service messages and provide- service messages. The client 
service messages group includes the description of all messages tiiat tiie cUent may send (tiiat tiie provider supports), 
and the provider service messages group includes the description of all messages tiiat tiie provider may send (tiiat 

25 the client receives). In one embodiment, either the client or provider may send a particular request to the space 
service to obtain a response message witii eitiien tiie entire client service messages, the entire provider service 
messages, the entire client and provider service messages, or a specific message of eitiier tiie client service messages 
or the provide- service messages. In addition, once a gate has been constructed, a client may query as to tiie . 
capabilities of the service witiiout tiie gate actually sending a message, but instead by inspecting the gate's set of 

30 . messages. 

As described above, a message gate may verify tiie sender of tiie message using an authentication 
CTedential, message content for type safety and accordiing to an XML schema. However, it may also be desirable to 
. verify that messages are sent between a client and a service in tiie correct order. It may be desirable to be able to 
provision applications (services) for clients to run witiiout any pre-existing specific functionality related to tiie 
35 application on the client (e.g. no GUI for tiie application on tiie client). For example, a Web browser may be used 
on a client as tiie GUI for a service instead of requiring an application-specific GUI. Of the possible messages in tiie 
XML schema, tiie client may need to know what message next to send to tiie service. It may be desirable for the. 
client to be able to determine which message to send next witiiout requiring tiie client to have specific knowtedge of 
tiie service. In one embodiment, tiie service may continually send response messages indicating tiie next mpyjt it 
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needs. The sendee would then accept only the corresponding messages from the client with the requested mput 
specified. Other ad hoc scheme for message ordering may also be employed. 

In another embodiment, a message conductor 160 may be employed in the gate or associated with the gate 
to verify tiie coirect sequence of messages, as opposed to verifying each message's syntax (vMch may akeady be 
5 performed in the gate according to the schema). Message conductor 160 may provide a more general approach for 
application provisionmg. . The message conductor 160 may be specified m a service's advertisement The message 
conductor indication in a schema may aUpw code to be generated on or downloaded to the client during gate 
construction, which may provide the choreography needed to decide which message to send next to the service. A 
message conductor may be implemented as a Java appUcation, a Java Script, WML script, or in other programming 

10 or scripting languages. 

In one embodiment, tiie message conductor may accept as input an XML document (e.g. from a service 
advertisement) tiiat presents the valid order or choreogr^hy for messages that may be sent between a cHent and the 
service. This XML document may also specify user interfece information and other rules. The conductor m^ parse 
. tiiis XML document into an intemal form and enforce message ordering (and/or otiier rules) according to tiie 
15 enclosed ordering information. The conductor may prevent messages from being sent out of order. Or, if a message 
is sent out of order, an exception may be rais^ within the sending device. If a message is received out of order, the 
conductor may send an automatic response message back declaring the ordering error. The sender may then resend 
messages in the conect order. Note tiiat in some embodhnents, part or aU of a conductor may be shared by several 
gates. Thus, a conductor may be linked to multiple gates. 
20 In one embodiment ofa distributed computing eiivironment, front ends for services (service m 

be buat in to clients. In one embodiment, tiie service interface may be a preconstructed user interfece provided to 
the client by tiie service. In one embodiment, the service interface may be provided to tiie cUent m the service 
advertisement The service mterface may interact on die cUent with tiie user of tiie service to obtain input for 
running tiie service, and then may display results of running tiie sendee on tiie client A "user^ may be a human, 
25 embedded system, another client of service, etc. In one embodhnent, a cHent device may not be able to provision 
arbitrary services, as tiie client device may only be able to run services for which it has a front end built in. In one 
embodhnent, a service interim for a service may be implemented in a Web bro^^ 

In one embodiment, a message conductor and/or service mterfece may be external to tiie gate and tiius 
abstracted from ttie gate and client The abstracted message conductor may provide provisioning of arbitrary 
30 services to any client device. In one embodiment, tiie message conductor may be written m code tiiat may run on 
substantially any platform. In one embodiment, tiie message conductor may be written in tiie Java language. In one 
embodiment, tiie message/conductor may. not require the arbitrary downloading of objects, for example, Java 
objects, returned to ttie client device. For example, very large objects may be returned, and tiie message conductor 
may choose to not download tiiese very large objects: In one embodhnent, tiie message conductor may send XML 
35- messages to services from tiie cHent device on behalf of tiie client The message conductor may interact with the 
user of the service to receive input and display results. 

In one embodiment, a service mterfece may be provided tiiat interacts witii tiie cUent (e.g. timi a user 
interfate) to obtain all infohnatioh to run tiie service, and tiien may display eitiier results of running tiie service or 
information regarding tiie location of results, as appropriate. The service interface may be either part of a message 
40 conductor 160 or may be in addition to and woric witfi message conductor 160. The service mterfece may eitiier be: 
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1 . Built in to the client device and thus run on flie client 

2. Downloaded to the client device from the space server. 

3. Run on the space server. 

4. Run on the service provider. 

In one embodiment, .to a client, the distributed computing environment space server must support #1 always, 
indicate if #2 is supported (by advertisement in space), indicate if at least one of #3 and #4 is supported: Note that 
whe&er or not it supports #4 depends upon vrhether or not the service provider supports #4. In one embodiment, to 
a service provider, the distributed computing environment space server must support #4 alvrays and indicate if it 
supports #3. 

Regardless of where the service interface runs, once a service is activated, tiie service inlerfece nay interact 
with the cHent, displaymg (remotely) requests for input on the cUent's display, and th^ 
ofrunning the service. Such interaction wifli the client is implemented in terais of XML messages. 

The service interfece and/or message conductor may meet Hxe needs of a client user that may have 
discovered a service, but does not want to read a typically large, dry computer manual to figure out how to use the 
service. As the service mterfece and/or message conductor interacts witii fte usw to request all inpvX fliat the service 
needs, they may even provide short descriptions of the input requested if the user requests it Once the service 
mterface has obtained the necessary information firom the client, it may send XML messages to the service provider 
that runs tiie service. The ordering of Ae messages may be .verified by the message conductor 160 in the gate.. 

In a preferred embodiment, all messages flow ftrough a gate. A gale may be Configured to provide a flow 
0 control mechanism For example, a service may need to handle a large amount of incoming and outgoing messages. 
How control may allow a service to keep up with high traffic volume. Gates may be. configured to monitor 
messages for flow control tags. When a gate receives a message^ it may examine that message for a.flow control tag. 
The flow control tags may be XML tags. A message may include either an OFF tag or an ON tag, for example. If a 
received message includes an OFF tag. the receiving gate will stop sending messages to its paired destination gate. 
15 If the gate receives a message including an ON tag. it may resume sendmg messages. 

TTius, a service-side gate may monitor the use of its resources and trigger flow control if use of its resources 
• exceeds a threshold. For example, a service may reduce its load by sending messages includmg OFF tags to one or 
more cUent gates. The client gates receiving the messages with OFF tags will stop sending messages to the service. 
Pending messages in the cUents may be buffered or may be handled by internal flow control it^^ Oncethe 
30 service is able to handle more requests, it may send messages to one or more cUents with ON tags so that the clients 
may resume sending messages. In other embodiments, other flow control tags may be supported in addition to or 
instead of ON and OFp. Other flow control tags m^ indicate to reduce message flow or that message flow m^ be 
increased. 

Message gates may be configured to perform resource monitoring. For example, since all messages may 
35 flow through a gate, the gate may be configured to manage and/or track a cKenfs use of a service (aid possibly its 
associated resources such as memory or threads). A gate may be configmed to track the activity of a software 
program, such as a client, by monitoring how much a resource, such as a service, is used or which and howmany. 
.service resources are used. In one embodiment a gate may generate or may fedUtate generation of a cUentaclivily 
log. Each message and its destination or sender may be logged. 
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A gate may also be conjagured to perform resource monitoring for flow control from the local (sending) 
side of a gate pair. If the client exceeds an allocated bandwidth of service (or resource) usage, the gate may ., 
automatically throttle back the flow of messages, for example. Thus, a client-side message gate may automatically 
trigger different flow control modes by monitoring the flow of OTitgoing messages. If the outgomg message flow 
5 exceedsathreshold,the gatemay reduce or shut oflF its flow of outgoing messages. The threshold may be specified 
in a service's XML schema or advertisement In some embodiments, the threshold may be specified only for 
messages using certain service resources or for all messages. . 

The gate may also be configured to determine when message flow may be increased or. resumed. In one 
embodiment, the gate may maintain a coimt of outgoing messages that have been sent without the niatching reply 
10 (response) received. When matching responses are received by the client-side gate, the count of outstanding request 
. messages may be deicremented. When the counts decrements below a specified outstanding request message 
threshold, the gate may mcrease or resume sending new request messages. 

A gate may be configured to support message-based accounting and/or billing. A billing system may be 
implemented based upon the number and/or kind of messages sent and/or received by a message gate. Since all 
15 messages to and from a client may pass through a gate, die gate may be configured to facilitate chargmg a chent for 
service usage, for example on a per message basis or "pay as you go". Thus, a billing system may be implemented 
within the distributed computing environment m which a user could be chained, for example, each time a message is 
sent and/or received by software running on behalf of the user. 

In one embodiment, a message gate may receive billing information from an XML schema, e.g. for a 
20 service. The biUing mformation may denote a billing policy and a charge-back UM The charge-back Uia may be 
used by the message gate to charge tune or usage on behalf of a user, A message gate may make a charge-back by 
sending a charge message to the charge-back URI specified m the XML schema. Gates so configured may be 
referred to as bill gates. The billing policy may indicate charge amounts per message or per cumulative message 
totals, etc. The billing policy may indicate how much and/or how oftai (e.g. after every x number of messages sent 
25 and/or received) to charge the user. The policy may indicate that only certain types of messages trigger charges, 
such a messages requesting a specified service resource. The billing policy may also indicate different billing 
models for different clients or classes of clients. For example, a billing policy may be configured (e.g. in a service's 
XML schema) so that some clients may pay a one-time charge vfhea they create a gate to access die service. The 
poHcy may indicate clients that are to pay as they go (e.g. per message), or m^ indicate clients that are not to be 
30 chaigedatall. 

In some embodiments, a client may be too thm to support a full gate, or a client may not include software to 
directly partic^)ate in the distributed computing environment In such embodimients, a server (such as the space 

: server in which the service is advertised or another server) may be a fiill or partial proxy gate for the client The 
server may instantiate a service agent (which may mchide a gate) for each service to be used by the client The 

35 service agent may verify permission to send messages; send messages to the provider, possibly queuing them until 
the provider can accept the next one; send messages to the client, possibly queuing therh until the client can accept 
the next one; and manage the storing of results in a result or activation space. See also the Bridging section herein. 

For example, as illustrated in Figure 13, a client may be a conventional browser 400 that does not support 
gates to participate direcfly in the messaging scheme described above. The browser 400 may be aided by a proxy 

40 servlet (agent) 402. The browser user may use a search engme to find a Web page that fronts (displ^s fee contents 
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of) a space advertising services vwthin the distributed computing environment Hie user is able to point and click on 
the space Web page and, with the help of the servlet, to access services. The Web pages may include sdripts, for 
example, Java or WML scripts, which may be used in connecting tiie browser to the proxy servlet Scripts may also . 
be \ised to send messages to the proxy servlet The servlet agent may translate Web page actions into messages oh 
behalf of the browser client ITiese actions may include navigating a space, starting services, and returning results. 
Result page URIs (referencing pages contammg XML) may be returned directly (or translated into HTML or WAP 
if needed) to the browser, for display to the user. Thus, the browser-based client does not need to know how to start 
services, nor which messages to send during the service usage session- For example, a user of a WAP browser (e.g. 
on a cell phone) may connect to a space page, browse its contents (services), and then start a service, all by pomtmg 
and clicking. The agent 402 provides the client interface between tiie conventional client and the distributed 
' computing environment 

The distributed computing environment may mclude several different ^es of message gates for 
communicating between cUents and services that support difiBerent features. For exan^)Ie, as discussed above, some 
gates m^ support flow control or billing. Another type of message gate may support a form of remote method 
invocation. This typeof gate may be referred to as a method gate. 

A gate is a secure message end^int that sends and receives type-safe messages, e.g. XML messages. Tlie 
remote method invocation (RMI) style gate may be referred to as a method gate. The direct data-centric gate may be 
referred to as a message gate. A method gate may be implemented as a "layer" on top of a message gate. The exact 
implementation may be defined in the platform binding. 

Figure 14 illustrates the use of a method gate to provide a remote method invocation interfece to a .service. 
Method gates provide a method mterfece between cUents and services. A method gate may be bi-directional, 
allowing remote method invocations from client to service and from service to clieiit A method gate 172 m^ be 
generated from XML schema mformation 170 (e.g. from a service advertisement hi a space). The XML schema 
mformation 170 includes XML defining a method mterfece(s). From this mformation, code may be generated as 
part of the gate for interfacing to one or more methods. Each method invocation (e.g. from a cHent apphcation 176) 
m the generated code may cause a message to be sent to the service containmg the marshaled method parameters. 
Hie message syntax and par^eters to be included may be specified in the XML schema. Thus, the method gate 
172 provides an XML message interfece to remotely mvoke a service method The method gate ma/ be generated 
on the client or proxied on a server, such as the space server \^ere the service method was advertised or a special 
gateway server. 

A service may have a corresponding method gate tfiat implements or is linked to a set of object methods 
that correspond to the set of method messages defined in the service's XML schema. There may be a one to one 
correspondence between the object methods implemented by or linked to tiie service's method gate and the method 
messages defined by die service's XML schema. Once a service's coixesponding method receives a message from a 
client to mvoke one of the service's methods, the service's method gate may unmarshal or ympzck the parameters of 
die message mvocation and then mvoke die method indicated by die received message and pass the uninarshalled 
parameters. 

The method gate may provide a synchronous request-response message mterface in which clients remotely 
"call methods causmg sauces to return resuhs. The underlying message passmg mechanics may be completely 
hidden from die cHent Hiis form of remote method mvocation may deal widi metiiod results as follows. Instead f 
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downloading result objects (and associated classes) into the client, only a result reference or references are returned 
in XML messages, in one embodiment. An object reference 178 may be a generated code proxy (e.g. results gate) 
representing the real object result 180 (still stored out on the net, for example). In other embodiments, ^e client 
may choose to receive flie actual result object In addition, once a client has received a result object reference, the 
client may use this reference to receive or manipulate tiie actual result object In one embodiment, the result 
reference includes one or more URIs to the real result 

The real result object(s) may be stored in a service results space (which may be created dynamically by a 
servlet, for example). This temporary results space m^ act as a query results cache. The results cache (spiace) may 
be patrolled by server software (garbage collector) that cleans up old result areas. Results returned frorn each 
method invocation may be advertised in the results space. A result itself may be or may include a method tiiat could 
then be remotely instantiated by a client, thus generating its own method gate. Therefore, the distributed computing 
enviroimient may support recursive remote method invocation. 

As mentioned above, when a client uses a method gate to remotely invoke a service method, a reference to 
the method results may be returned from the service method gate instead of the actual results. From this reference, a 
results gate may be generated to access the actual result Thus, the client or client method gate may receive a result 
URI and perhaps a result XML schema and/or authentication credential for constructing a gate to access the remote 
method results. 

In one embodiment, a service gate may create a "child gate" for the results. This child results gate may 
share the same authentication credential as its parent gate. In some embodiments, results vasty have a different set of 
access rights and thus may not share the same authentication credential as its parent For example, a payroll service 
may allow a different set of users to initiate than to read the payroll service's results (paychecks). 

A service method gate may return a child results gate to the client gate as the result of tiie method. The 
client may then use the results gate to access the actual results. In one embodiment, the software program (client) 
receiving the results gate cannot distinguish between the results gate and the result itself m which case the results 
gate may be an object proxy for the actual result object The results gate may also be a method gate that supports 
remote method invocation to resiilt objects. In this marmer, a chain of parent and child method/results gates may be 
created. 

In one embodiment, the method gates and remote methods may be in Java. In this embodiment, method 
results are correctly typed according to the Java typing system. When a Java method is remotely invoked as 
described above, the results gate may be cast mto the Java type that matches the result ^e. In this embodunent, 
method gates may be used in tiie distributed computing environment to allow remote Java objects to behave as local 
Java objects. The method invocation and results may appear the same to the client Java software program whether 
the real object is local or remote. 

See the Spaces section below for a further discussion on the use of spaces for results. 

Message gates may also support publish and subscribe message passing for events. Message gates with 
event support may be referred to as event gates. A service's XML schema may indicate a set of one or more events 
• that may be jpublished by the service. An event gate may be constructed from the XML schema. The event gate 
may be configured to recognize some or aU of tiie set of events published by a service, subscribe to those events, and 
distribute each event as the event is produced by the service. * 
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The set of events for a service may be described in the service's XML message schenaa. For each event 
message in fee XML schema, the event gate may subscribe itself as a consumer of that event In one embodiment, 
an event gate subscribes to all events indicated by the XML schema. Each event message may be named using an 
XML tag. The event gate may subscribe by sending a subscription message including the XML tag for the event to 
5 be subscribed to. 

When a corresponding event occurs with the service, the service may send an event message to subscribers 
indicating the occurrence of the event The event message may contain an XML event document and may be sent to 
each subscribed gate. When a subscribed gate receives the event message, fee XML event document is removed 
from fee message and fee process of distribution begins. Event distribution is fee process of handitig out fee event 

10 document within fee client platform. Each event consumer within fee client platform may subscribe wife fee event 
gate for each type of event On Java platforms, fee typing system is Java (converted from fe 

The event consumer may supply an event handler callback mefeod to fee event gate. The event gate m^ 
store a list of feese subscriptions. As each event message arrives at fee gate (from fee service producing fee event), 
fee gate traverses fee list of client consumers and calls each handler mefeod, passing fee XML event document as a 

15 parameter. In one embodiment, fee XML event document is fee only parameter passed to fee handler callback 
niefeod. 

In one embodiment fee event gate automatically subscribes itself for events on behalf of fee local consumer 
clients. As cUents regjbster intei^ vwfe fee gate, fee gate registers interest wife fee eve^^ A client 

may also un-subscribe interest, which causes fee gate to un-register itself wife fee service producing fee event 
20 An event gate may type check fee event docunient using fee XML schema just like a regular message gate 

does in fee standard request-response message passing style described above. An event gate may also include an 
aufeentication credential in messages it sends and verify fee aufeentication credentials of received event messages. 

Note feat airy combination of fee gate functionality described above may be supported in a single gate. 
Each type has been described separately only for clarity. For example, a gate may be a message gate, a mefeod gate 
25 and an event g?Lte, and may support flow control and resource monitoring 

Service Discovery Mechanisms 

In one embodiment, fee distributed computmg enviroranent may include a service discovery miechanism 
. . that provides mefeods for clients to find services and to negotiate fee rigbts to use some or all of a service's 
30 capabilities. Note that a space is an example of a service. The service discovery mechanism may be secure, and 
may track and match outgoing client requests wife incommg service responses. 

A service discoveiy mechanism inay provide various c^abiUties including, but not limited 

• Findmg a service using flexible search criteria. 

• Requesting an aufeori2ation mechanism, for example, an aufeentication credential, feat may c^^ 
35 client fee right to use fee entire set or a subset of fee entire set of a service's capabilities. 

• Requesting a credential, document, or ofeer object that may convey to fee client fee service's interfece. In 
one embodiment, fee service's interface may mclude interfaces to a requested set of fee service's 
capabilities. 
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• The tracking of discovery responses to the original requests. In one embodiment, each client request may 
include a collection of data that may also be returned in matching responses, thus allowing the requests and 
responses to be correlated. 

In one embodiment of the distributed computing environment, a service discovery mechanism may provide 
a flexible search criteria based upon an extensible graahmar. In one embodiment, a service name, service type, and 
other elements, if any, being searched for may be matched with elements in an XML document In one embodiment, 
the XML document is the service advertisement for the service. XML may provide a flexible, extensible granmiar 
for searching. XML also may provide type safety for matching elements. In one embodiment, the service names 
and service types may be type checked with the element types in the XML service advertisement 

In one embodiment, a distributed confuting environment may include a mechanism for clients to negotiate 
service access rights. In one embodiment, the mechanism may be used to negotiate for a subset of a servicers foil 
capabilities. The result of the negotiation may be an autiiorization such as an authentication credential that conveys 
to the client the right to use the requested subset of the service's capabilities. 

In one embodiment, tiie service discovery mechanism may allow a client to request a security capability 
credential from a service. In one embodiment, the client may present to the service a set of desired capabilities in 
the form of a protected (secure) advertisement The service may then respond with a c^)ability credential ftiat may 
convey to the client the rigjits to use the requested capabilities described in the protected advertisement 

In one embodiment, the distributed coinpudng environment may include a mechanism for a client to 
negotiate service access rights and to then obtain a security credential or document that may be used to present the 
service's access interfece to the set or subset of the service's capabilities feat were requested by fee client 

In one embodiment, a client feat receives a capability credential from a service may generate a custom 
service access interfece document feat may be referred to as a ''complete advertisement" hi one embodiment, fee 
complete advertisement may be an XML document The generated advertisement may provide access to fee service 
c^abihties as granted to fee client by fee received capability credential In one embodiment, an interfece may be 
provided by fee advertisement only to fee service capabilities to which fee client has been granted access by fee 
capability credentiaL In one embodiment, fee chent may be granted access to only required capabilities and to 
which fee client has access privfleges. 

In one embodipaent, fee distributed computing environment may provide a mechanism by vMch a client 
may negotiate capabilities vwfe services. In one embodiment, fee client may negotiate its capabilities to fee service. 
ITie service may feen customize results based on fee parameters negotiated wife fee cUent For exanq)le, a chent 
feat is capable of one bit display at a resolution of 160x200 may negotiate feese parameters to fee.seryice, feus 
allowing fee service to customize results for fee client 

The following is included as an example of an XML capabilities message and is not intended to be Imiiting 
in any way: 

<type name="Capabilities"> 

<element name="display" type="string"/> 
<elemcnt name=="memory" ^pe="string"> 
<elementname="mime" t>pe="sting"/> 
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</type> 

The distributed computing enviromnent may include a mechanism that may allow clients to negotiate how a 
service is to return results of a service invocation. In one embodiment, during a capability credential request, a 
means by which to choose one of the results return methods may be conveyed to the service. The service may then 
generate a custom service advertisem^t that may convey to the client the results mechanism to be used, as well as 
the sendee interfece. 

Thus, the service discovery protocol may allow clients to search for services (both space services and 
specific services or types of services). Service providers (or a listener agent) may respond to search requests by . 
publishing or providing corresponding advertisements or URIs to corresponding advertisements. When a service 
provider responds to a discovery search request (either directly or through a listener ageiit), the provider may choose 
to publish a protected or an un-protected (complete) advertisement A protected advertisement may include the set 
of information necessary to obtain a complete advertisement Publishing a protected advertisement forces the client 
to obtam a valid credential from an authentication service before receiving the complete un-protected advertisement 
from the service provider. A conq>lete im-protected advertisement is needed to create a gate, and tiierefore to use 
the service. Forcmg clients to obtain a valid credential before receiving an advertisement may provide an additional 
level of security for the service provider. The security credential tiiat must be obtained to receive the complete 
advertisement may be the same security credential that is used to construct a gate to communicate with the service 
where the gate embeds the security credential in each message to the service. 

Whether or not a service provider publishes a protected or complete advertisement may be based upon the 
service provider's desired level of security. Complete advertisements contain the service's message endpoint URL 
Concealing this address rnay be a desirable security featm^ in many kinds of networks and deployment 
environments. However, simple proximity networks like IRDA, validate clients by requiring the client be in close 
proximity to the service provider. Concealing the IRDA message address from a close proximity client may just be 
redundant or too burdensome. In eitiier case, the discovery search response choice m^ be left to the service 
provider- In a preferred embodiment, clients (or client gate fectories) are configured to process eitiier isearch 
response. 

Tuining now to Fig. 41, a flow chart illustrating service discovery is illustrated according to one 
embodiment A client locates one or more advertisements for service(s) the client may desire to use, as indicated at 
2072. In one embodiment, the client may locate services by sending a search message. Turning now to Fig. 42, a 
flow chart illustrating a more detailed example of locating service advertisements is illustrated for oiie mbodiment 
The client may send (e.g. broadcaist, multicast, etc.) a search message indicating service name and/or service type 
search criteria, as indicated at 2071. 

The following is an example for. one embodiment of a search message that may be sent on one or more 
available message transports when a client wishes to search for services: 

<Discover> 

<Search> • 
<SearchTyp^ Type</SearchType> 
<SearchName> Name</SearchName> 
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<SearchConmient>Confflient</SeardiConuneiit> 

</SearclP' 
</Discovei> 

5 Tbt search message. is fomatted accoriing to a data representational language. The search and discoveiy 

tags may be required. TTie search tags may contain an optional set of search criteria, useful for nano>viDg the 
possible results returned from service piovidere. Hie optional search oiteria components may inchide a name (e.g. 
String). The name is compared with a service's name. If the search name matches the beginning or all of the 
service's name, a match may be declared for that service, to one embodiment, if the name isn't provided, all service 
10 names are considered a match. 

The optional search criteria components may also inctade a^.(e.g. String). TTie type is compared vrith 
Ihe service type, e.g. m the service description's "Title" field. If fee seardi type matches Ihe begmnmg or aU of &e 
service's type, a match may be declared. In one embodhnent. if the type isn't provide4 all service types are 
considered a match. For example, the type string may be "space-- ^en operating on a large nctwodc or "seivice'' 
15 when operating in a proximity network. Additionallevels of type may be employed. 

Thus, as indicated at 2072 inFig. 42, the service name and/or service type search criteria maybe compared 
tonameandtipeinformationforservicesTViflunthedistnTnitedcomp^ Each service provider that 

receives the search message may perform this comparison. Or a listener agent may perfomi the comparison for 
services registered with the listener agent 
20 -Hie optional search criteria components may also include a comment (e.g. String). TTie comment string 

may be returned in the body of the response message, and may be a useful discoveiy message tracking tooL For 
example, a timestamp mi^t be a useful comment string. 

A search response may then be returned to the client mdicating advertisements for services that match the 
search criteria. lUe foUowing is an example for one embodiment of a service provider response message that may 
25 be sent (e.g.unicast) by a service provider in response to the search message: 

<Discover> 
<SearchResponse> 

<SearchCoinment> Comment String<SearchCominent> 
30 <Advertiseinent;> Advertisement! <yAdvertisement> 

<;Advertisement> Advertisement2 <Advertisemen£> 

<Advertisement> AdvertisementN </Advertisement> 
<ySearchResponse> 
<Discover> 
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ITie response message may include the set of advertisements tiiat match the search criteria. In one 
embodhnent. if the search criteria wei^'t suppHed, all available advertisements are defined as a match. In.one 
embodhnent. if a comment string was suppHed, the response also contams tiiat same comment, possibly with an 
additional comment appended to the end of the ori^al string. 
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As mentioned above, a service may publish either a protected advertisement or a complete advertisement 
Thus the advertisements indicated in a response to a search may be protected or complete advertisements. A 
protected advertisement may not indicate the actual URI or schema that may be used to access the service. Instead, 
a protected advertisement may contain information on how to obtain a complete advertisement that includes the URI 
and schema to access some or all of a service's capabilities. In one embodiment, a protected advertisement may 
include the following information: 

• Kame and type of the service. 

• Capability descriptions of the service. 

• UUip of the service, 

• URI of authentication service, vvliichvydfl retnm a suitable cUent access (capabi^ . 

• URI where the credential and UUID may be sent to generate a complete service advertisement 

A protected advertisement may be a smaller, surrogate XML document fragment (a meta-^vertisement). 
A protected advertisement may provide a level of indirection between the cUent and the real advertisement, 
requiring the client to negotiate for access to the real advertisement Publishing a protected advertisement instead of 
a complete advertisement forces the client to obtain a valid credential from an aothenticaticm service before 
receiving the complete un-protected advertisement from the service provider. 

Returning to Fig. 41, after the client receives a response to it s search, it may select one of the 
advertisements for one of the services for wlaich it wishes to negotiate access by requesting a capability credential, 
as indicated at 2074. This advertisement negotiation process may provide additional security . in tiie distributed 
computing environment (e.g. by hiding real advertisements), while at the same time adding some flexibility. For 
example, during the advertisement negotiation process, a client may request a custom set of messages for accessing 
the service. The client may provide the desired name and type of mterface. One example of requesting a custom set 
of messages may be requesting only "read" access as opposed to "read" and *Svrite" access to a service. When 
requesting ia custom message set, the client may wish to only use a subset of the service's fiill capabilities 
(messages). The right to use the requested set of messages may be verified during the negotiation. If the client 
doesn't have the proper access rights to the requested capabilities, the negotiation fails, otherwise a yahd credential 
is returned to the client 

A client may also request additional access message sets. Client may provide tiie desired name and type of 
interfece. Some clients may require the use of more than just the base access messages, A client may request a set 
of additional access messages. Some of these access messages may even address platform specific issues such as 
performance and memory fooq)rint size. 

A client may also request that a non-XML content type be used to represent data passed iii tiie messages 
between client and service. Some clients m^ not support XML, but still wish to access services withm the 
distributed computing enyironotnent To allow non-XML clients access to services, non-XML content may be 
tunneled within an XML message. TTie non-XML content may be wrapped by an XML tag on the sending side, and 
then extracted on the receiving side: 

Service providers may benefit from the use of protected advertisements m sev«^ ways. As already 
rnentioned, protected advertisements prevent unauthorized clients from receivmg complete advertisements, and 
allow capability negotiation. Protected advertisements may also allow for dynamic advertisement generatioru When 
a client negotiates for a complete advertisement, an opportunity to generate a custom one "on the fly" exists. This 
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feature allows smaller XML document fragments to be dovmloaded to clients since the complete advertisement need 
be only as big as requested. Hiis feature also allows a service to effectively publish advertisements specific to client 
requirements. 

Protected advertisements may also fecilitate service queries. Protected advertisements may be published 
5 instead of complete advertisements to facilitate dynamic searches for services that match the client requested set of 
capabilities. Protected advertisements may indicate a service's capabilities in a searchable format without including 
a complete message schema for those fecilities. 

In one embodiment, a protected advertisement may include the foUowmg XML document elements: 

• Name (Human readable, non-canonical string) 
lb • Canonical name of service (e.g. UUID) 

• Base Method Interim Description (Message Intofiu:eDescn^ 

- Tide (Message interfece standard name that conveys a type) 

- Provider Name (Standards Body Name) 

- Version (Version of standard (type) implemented) 
15 . - Info URI (Standard body's web page) 

• Additional Access Method Interfece Descnptions 

- List of descriptions containing: Titie, Provider, Version, Info URL 

• Content Type Descriptions 

- List of descriptions contaiiiing: Titie, Provider, Version, Info URI. 

20 • Credential 

- Service's credential to enable client to authenticate service 

• Authentication URI 

- A inessage may be sent here to obtain a suitable credential that grants access to this service. 

• Generate Real Advertisement URI 

25 - A message may be sent here to generate a complete advertisement, given a protected advertisement 

that contains the client's requested capabilities. 
To obtain a complete advertisement, given a protected advertisement, a client (e.g. client's gate fectoiy) 
obtains a capability credential from the specified autiientication service by sending a credential request message, as 
indicated at 2074 in Fig. 41. The credential request message m^ be sent to an authenticated service URI specified 

3d in the advertisement for the service the client desires to access. When the client's request is received, a capability 
credential is generated, as indicated at 2075. The capabiHty credential may be generated according to capabilities 
requested by the client and/or the client's level of authorization. The client then receives the capability credential ia 
respoiise to its request, as indicated at 2076. The response may contain tiie credential needed to generate the 
complete advertisement This credential may be the same credential that the client's gate mcludes in each naessage 

35 sent to the service. 

If the advertisement was a protected advertisement, the client then may send an advertisement request 
message containing the capability credential and an identification. (e.g. UUID) of the service to the second URI 
. specified in the protected advertisement, as indicated at 2078. The client then receives a complete advertisement, as 
indicated at 2080. The response to tiiis second message is the complete advertisement of tiie specified service. If 
40 the advertisement mdicated in the credential request was.already a complete advertisement, 2078 and 2080 may be 
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skipped. Figure 43 compares the difference in the discover process -when 1he published advertisement is a complete 
advertisement versus a protected advertisement Returning to Fig. 42, a conq)lete adv^tisemrat and the capability - 
credential may then be used to create a gate, as indicated at 2082. 

An example of a credential request message according to one embodiment is as follows: 
5 ■ ■ ■ . 

<Discover> 
<CredentialRequest> 

<JUID> uuid</UUID> 

<;AdvertisementtJEU>adv uri</AdvertisementURl> 
10 <ProtectedAdvertisemene> adv</ProtectedAdvertisement> 

</CredaitialRequcst> 
</Discover> 

The credential request message may include an identification (e.g. PUID) of service to which access is 
15 desired The credential request message may also include an advertisement URI referencing the advertisement or 
the advertisement (by value). The Advertisement may be passed by vahie or by reference during this negotiation 
process. Advertisements may be conq)lete or protected. If the advertisement passed in the onedential request 
message is already a complete advertisement (e.g. service returned it in the se^ch response^ then the credential 
returned from the service will allow access to all of tiie service's capabilities (all access methods + all messages). 
20 A protected advertisement may be edited to contain just tiie desired set of access method and content 

descriptions. The edited protected advertisement may be passed in the credential request message. Thus, a client 
may build and expresses its set of requested capabiHties by editing the adveitisememt, or copymg the relevant 
information jfrom the original to a new instance. 

An example of a credential request response message according to one embodiment is as follows: 

25 

<Discover> 

<CredentialRequestiResponse> 

<Credential>capability credentiaKCredential> 
<yCredentialRequestResponse> 
30 </Discover> 

If the client has proper authorization, tiie credential request response message includes a capability 
credential giving the client requested access to the specified service (e.g. identified by UUID), includmg the set of 
capabilities defined in the protected advertisement This credential may then be stored in the client's gate and tiien 
35 added to each message sent to the service. The service then uses this credential to verify the client's rigjit to use a 
service's capabilities. 

The capability credential structure and contents may be defined by the service. In one embodiment, the 
credential at least mcludes a reference to tiie protected advertisement used during the negotiation, and a security key 
to validate the client's identity. If tiie advertisement passed in the credential request message is ahea^ a complete 
40 advertisement (e.g. service returned it in the search response), then the credential returned firoin the service will 
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allow access to all of the service's capabilities. If the service provider doesn't siq)port or require credentials at all, 
the response message may contain an empty credential (null). 

In some embodiments, a capability credential may be used to support the notion of sessions, A service 
provider may embed a session ID within tiie credential, and be sure tiiat the client gate will pass it (credential 
5 . containing ID) to tiie service provider in each message. The en^ 

. and hence may contain any number of fields, including a sessionlD. or other demuxmg IDs, etc: 

An example of an advertisement request message according to one embodiment is as follows: 

<Discover> 
10 ' <AdveftisementRequest> 

<Credential> cjqsability credential<^Oedentia> 

</AdvertisementReqQesl> 
</Discbver> 

15 The advertisement request message inchides the credential from tiie credential request response message. 

In one embodiment, this credeiitial includes enougji information to identify the origmal protected advertisement 

An example of an advertisement request response message according to one embodiment is as follows: 

20 . <Discover> 

<AdvertisementRequestResponse> 

<Advertisement> ConipleteAdvertisementl </Advertisemari> 
</AdvertisementRequestResponse> 
</Discover> 

25- 

The advertisement request response message includes tiie complete advertisement referenced by the 
. (edited) protected advertisement Note that tiie credential found in ifae cotnplete advertisement may be tiie gate 
credential to be passed in every message. 

Spaces are implemented by services of type space. Discovering a space may be accomplished either by 
30 specifying tiie "space" type in tiie seardi criteria, or by parsing tiie set of search results, and tixen extracting all 
"space" advertisements. Spaces may be populated witii advertisements (jwotected or unprotected) using tiie above 
described discovery protocol. The population may be initiated by tiie space service itself or by anotiier network 
service agent .. 

Once a space is discovered, its contents may be examined using standard space service navigation 
35 messages or as defined in flie space service advertisement For each advertisement witiiin tiie space, a client gate 
factory may build a gate (using tiie credential and advertisement request messages) to access tiie named service. 

In one embodknent, all advertisements (protected and complete) contain a service credential. Clients msy. 
vaHdate tiiis credential before requesting a cUent capabilify credential This procedure may prevent un-autiiorized 
services fit)rii publishing advertisements iising the discovery protocol 
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For one discoveiy protocol implementation example, tiie protocol may be 'on the wire data fonnat, v*ich 
may be implemented in many different ways depending on the transport beneath it The discoveiy protocol 
implementation may be defined in a platform bindmg. For example, a possible IP fanplementation may be one in 
which space services listen for UDP multicasts of space search messages. A client/service may multicast a space 
5 search message and waits for a response. Space services may unicast a space search response message contahung an 
advertisement 

In one embodiment, the ^stn^vited computing enviromnent may mclude a mechanism for tracl^ 
discoveiy search requests and responses to die requests. In one embodiment, search request and response messages 
may include a field that may be used to include a string or ian XML document In one embodhnent, the strmg or 
10 XML document included m the field of a request message is also returned in the response message.. In one 
embodiment, fee string or XML docmnent is required to be letmned in the response 
flie string or XML document may mctade additional information inserted in or appended to fte sttm 

when returned m the response message. In one embodhnent, this mechanism may be used m debuggmg complex 
systems. In one embodiment this mechanism may also provide to clients a method for choosing services to access 
15 by using the string or XML document to pass custom search information between a cUent and service 4at may onfy 
be understood by fte client and service. 

For an example of fields m request and response mess^ refer to the iSearchComment field m flie search 
and search response messages described above. 

For some devices that provide a service, flie overhead of finding a space to advertise its service and 
20 maintain that advertisement is undesuable. hi one embodiment rather ftan searching for andmamtammg a space or 
spaces to pubUsh service advertisements, services on some devices may transmit their advertisements m response to 
comiection requests. For example, a printer device with a printer service that is available on a proxhnity basis may 
not mamtam an advertisement in a space (on the device or external to the device). Instead, when another device 
establishes a connection with the printer device (for example, a user with a laptop nimring a client deshes to print a 
25 document), the printer service may transmit the service advertisement to provide the XML service schema for 
connectmg to and runnmg the service that provides printmg fimctionality on the printer device. Also, some devices 
may only mamtam advertisements for then- services m a certain vicmity or local netwoik. Such a device may not 
deshe to siq)port or may not have access to transports for broader accessibflify. 

One example of a service device m which it may be desirable for the device to avoid or Ihnit mamtammg 
30 service advertisements m a space is a device whose fimctionality is avaUable on a proxhnity basis. Proxhnily-based 
services may provide advertisements of thefr fimctionality upon request These advertisements may 
accessible. For example, proxunity-based services m^ be proWded m a wheless communications system. The term 
"wheless" may refer to a communications, monitoring, or control system m which electromagnetic or acoustic 
waves cany a signal through atmospheric space rather than along a wire. In most wireless systems, radio fi«quency 
35 (RF) or mfi^ (IR) waves are used. TypicaUy. «» proximity-based wireless systems, a device conqnismg a 
transceiver must be withm range (proxhnity) of another device to estabUsh and mamtam a M 
A device may be a hub to connect other devices to a wireless Local Area Network (LAN). 

As mentioned, embodunents of the distributed computmg envux)nment may provide a mechanism usmg one 
or more spaces that allow cUents to rendezvous wiA services, fa a proxhnity computing envhonment, onie 
40 embodhnent of the distributed confuting envhonment may provide a service discoveiy mechanism that cUents m^ 
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use to discover sendees without using spaces as rendezvous points. An exanq)le of a proximity computing 
environment is an IrDA point^o-pomt conmiunications environment In a pn)ximity computing environment, the . 
proximity mechanism may find the "physical" location of the service for the client For example, in an IrDA 
environment, the client device may be physically pomted at die device including the service(s) that the client desires 
5 to use. 

In some situations a client may have physically discovered the device that contains services the client 
desires to run. For example, a person with a FDA cHent may be in close proximity to.a printer participating within 
die distributed computing environment Various scenarios may emerge with close pro>dmity devices. When clients 
are in close proxunity to devices (e.g^pubUshing services), much of the discover In 
10 these cases, the user may select the device. For example, IRDA devices are pointed at each other to establish a 
discover connection. 

Close proximity devices for which security isn't an issue (like an IRDA printer) may publish coniplete 
advertisements. Instead of encapsulating services in spaces, close proximity devices may directly respond to the 
discovery protocoL 

15 Close proximity devices for which security is an issue (e.g. an ATM) may respond to discover requests 

with protected space advertisemraits- The space may contdn all the services suj^Kxrted by ti» device. Once access 
to tiie space has been granted, clients may browse complete advertisements stored in Ac space. This model 
presumes that all services stored in the space can leverage the space security model, and not provide a separate 
model Alternatively, close proximity devices for which security is an issue may respond to discover requests with 
20 protected advertisements for each service. Each service may provide its own authentication service. Combinations 
of .each proximity device scenario are also contemplated- 

The proximity service discovery mechanism may enable the client to directly look for service 
advertisements rather than sending a search request to a space to look for service advertisements. Smce the cUent 
device may have established a proximity connection to the service device, the cHent m^ dtredfy request the desired 
25 service. For example, a PDA client device may establish a proximity connection to a printer device; the client may 
"know" to request a printer serWce cormection on the printer device. 

In one embodiment, the client may send a proximity service discovery message to the service device. The 
message may include mformation that may specify a desired service on the service device to which the cUent device 
has a proximity connection. In one embodiment, a service on the service device m^ respond to the proximity 
30 service discovery message, and may send to the client the service advertisement that the cUent m^ use to connect to 
the desired service. The proximity service discovery message may also include information that may be used to 
authenticate the client and to establish the cUent's capabUities on the service. Usmg the received service 
advertisement, the chent may establish a gate to establish coinmunication with the desired sm^ 

An example of a system m which a client device direcdy discovers a service on a service device over a 
35 proximity Imk is illustrated in Fig. 44. A client device 2150 includes a proximity port (e.g. an IrDA port) 2156 
configured to form a direct pomt-to-point communication link, or proximity link Client device 2150 may include a 
tlient 2152 that may desire to use a service over the proximity link. The client 2150 may be an application or a 
/ combination of cuxiuitry and software. A cUent interfece 2154 may be configured to directly request over the 
proximity link a document that describes an iiiter^ to access a desired service. The interfece 2154 may also be 
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configured to receive such a document directly over the point-to-point communication link and use the infomuition 
from the document to access the service, such as by constructing a gate. 

A service device 2170 may include a proximity port 2172 and may form a proximity link with client device 
2150. The service device 2170 may include code and/or hardware to implement one or more services 2176. 
Service device 2178 may also be configured to provide one or more documents 2178, or advertisements, over the 
proximity link. An advertisement 2178 may describe a message schema for acceissing a SCTvice 2176 provided by 
service device 2 1 70. A service interface 2 174 may be configured to receive over the proximity link a request from a 
client for a document 2178 that describes an interfece to access a service 2176. The mterfece 2174 may also be 
configured to provide document directly to a cUent over tfie proximity link and provide a message endpoint (e.g. 
gate) for communicating with a client The service interfece may also provide a mechanism to authenticate clients* 
requests to access the service. 

Figure 45 iHustrates a basic flow diagram iUustratingcHent discovery of a proxiniity service. Aclientmay 
form a pjroxhnity connection to a service device, as indicated at 2190. For example, a client device may be a 
personal digital assistant (PDA) with an address book client The client my need to print a jportion of tiie address 
book. The PDA may include an IrDA port and may be. in proximity of a printer whh an IrDA port The client may 
establish a proxnnity connection to the printer. The cliait may then, as indicated at 2192, request a service 
advertisement over the proximity connection, such as a pifinto- service advertisement Ihen client may tiien receive 
aa advertfeement matching its request, as indicated at 2194. The advertisement may be received dhectiy firom the 
service device over the proximity coimectioiL The client may then construct a gate according to the advertisement 
to access the service, as indicated at 2 1 96. 

Thus, proximity devices may avoid the overhead of using spaces as a rendezvous point for clients 
discovering services. Nevertheless, it may still be desirable to publish advertisements for services (e.g. proximity- 
based services) that do not desire to or cannot maintain their advertisements in a space tiiat is broadty accessible. In 
one embodiment of a distributed computing environment, a device that establishes a connection with a device that 
does not publish its service advertisement(s), such as a proximity-based device, may publish service advertisements 
received from the non-publishing device. For example, a device that establishes a connection with a proximity- 
based device and that has an altemate transport coimection(s) may publish (or republish) service advertisements 
reived from the proximity-based device in the altemate transport environment, thus allowing the proximity-based 
device service(s) to be used by other devices (through the (re)published service advertisements) which are outside 
the normal proximity range of the device. 

The publishing device may locate a locally published service advertisement for the proximity-based device 
through a discovery and/or lookup service, or alternatively the service advertisement may not be published by the 
local service device, but instead may be sent to the publishing device by the local deyice upon the establishment of a 
proximity connection, as described above. In one embodiment, the republished service advertisement may be made 
available as long as the device maintaining the advertisement is connected to or able to connect to the local device. 
For example, if the publishing device is disconnected fixjm the local device (for example, moves out of proximity 
range of the device), the service advertisement may be made stale or removed. A lease mechanism may be provided 
to allow the space containing the advertisement to send lease renevral messages to the publishing device. The 
" publishing device may verify its connection to the local device, thxis allowing the space to detect when the local 
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device is no longear available. Rules for how the service advertisements are republished msy be provided by the 
local device or by an administrative policy for the local vicinity (e.g. proximity area) or local network. 

Figure 24 illustrates an epcample of a device bridging proximity-based devices onto another transport 
mechanism to allow the services provided by the proximity-based devices to be accessed by devices outside the 
proximity range of the devices, according to one embodiment A publishing device 1404 may be connected to a 
network 1412, such as an Ethernet LAN or the Internet, etc., and may establish and maintain proximity connections 
1414 with proximity devices 1400 and 1404. Proximity coimections may be wireless connecdons or wired LAN 
connections, for example. Proximity devices 1400 and 1402 njay each send a sendee advertisement to tiie . 
publishing device 1404 upon connection, or, alternatively, the publishing device may locate the service 
advertisements using a discovery and/or lookup service for the proximity cormections. The publishing device 1404 
may then make the services provided by tiie proximity devices available to otiier deidces 1408 and 1410 on the 
network 1412 by republishing the service advertisements 1416 and 1418 in space 1406. Space 1406 may be stored 
on the publishing device or on other devices coimected to tiie LAN (including devices 1408 and 1410). 

Other devices on the LAN including devices 1408 and 1410 may then discover space 1406 and look up the 
republished service advertisements 1416 and 1418 for the proximity-based devices, establish gates to conmnmicate 
to those services (device 1404 may act as a proxy <xr bridge) on the proximity-based devices 1400 and 1402 using 
flie XML message passing methods described previously, and send requests and receive results to the proximity 
devices. Publishing device 1404 may act as a bridge between the network 1412 and the proximity coimections 1414 
to the proximity-based devices. 

Matching Component f Service! Interfaces 

The distributed computing environinent may provide a nlechanism for matching a compoiient (for example, 
a service) specification interface with a requested interface. For example, a client (which may be a service) m^ 
desire a service that meets a set of interface requirecdents. Eadi component m^ have a description of the interface 
to which it conforms. The specification hiterface matching mechanism m^ allow a component that best matches a 
requestor's interface reqiiirements to be located. The specification interface matching mechanism may also allow 
for "fuzzy** matching of interface requirements. In other words, the mechanism m^ allow matdiiiig without 
requiring the exact specification of all aspects of liie interface, &us providing a nearest match (fiizzy) mechanism. 
In one embodnnent, the specification interface matdiing mechanism may be implemented as a multi-level, sub- 
classing model rather than requiring specification at a single interface leveL 

In one embodiment, a component may use an XML Schema Definition Language (XSDL) to describe its 
interface. XSDL may provide a human-inteipretable language for describing the interface, simplifying activities 
requiring human intervention such as debuggnag. In one embodiment, the interface description may be provided as 
part of an advertisement (for example, a service advertisement) as described elsewhere in this document 

Using the specification mterface matching mechanism, a basic desired interface may be compared to a set 
of componenf interface descriptions. One or more components matching the basic desired interface may be 
identified. The interface descriptions may include subclass descriptions describing more specifically the interfaces 
provided by the components. In the search process, tiie class type hierarchy msy be exammed to. determine if a 
given class is a subclass of the search type. In one embodiment, subclasses may inherit properties of the base class, 
and thus the subclass-specific information may not be examined in this.phase. Thus, the search may be performed 
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generically; The identified components may be searched at the next (subclass) level The search may become 
specific to the subclass and may be performed by interpreting tiie subclass inftyrmation inchided in the interface 
description. ThQ search may continue through one or more subclasses until one or more components is determmed 
\;^^ch may provide the nearest match to the requestor's desired interfece. 
5 In one embodnnent, an interface matching mechanism m^ provide the abili^ to distinguish among two or 

inore components that nnplement simOar interfeces. hi one embodiment, the interface matching mechanism naay 
provide the ability to distinguish among different revisions of the same com^ 

In one embodiment, a conq)onent description may be provided that includes a specification of the interfece 
to which tiie component conforms. The component description may also include infonhation about the component 
10 itseli The interfece description and/or the component ioformation m^ be used to differentiate ainong diffOTol 
implementations of a given interfece. The conq)Qnent desaiptions may include a canonical identifier and version 
information. The version information may allow component revisions to be distinguished In one embodiment, the 
component description m^ be provided as part of an advertisement (for example, a service advertisement) as . 
described elsewhere m this document 
15 In one embodiment, components may be searched for a particular canonical identifier. Two or more 

conqwnents xosty be identified with matching canonical identifiers. One or noore conqKments may be selected from 
among the components with matching canonical identifiers. The selection procedure may use an interfece 
specification version, a component implementation specification, a component miplementation specification version, 
other mforaiation or a combination of information fi-om tiie component descrq)tion to produce a set of one or more 
20 components that best match the requestor's requirements. 

Spaces 

As mentioned above, tiie distributed computing environment relies on spaces to provide a rendezvous 
mechanism tiiat brokers services or content to cHents. Figure 15 iUustrates the basic use of a space 114. Service 
25 providers may advertise services in a space 1 14. Clients 1 10 may find tiie advertisements m a space 1 14 and use the 
information from an advertisement to access a service usiag the XML messaging mechanism of the distributed 
computing environment Many spaces may exist, each contamic^ XML advertisements tiiat describe services or 
content Thus, a space m^ be a repository of XML advertisements of services and/or XML data, which m^ be raw 
data or advertisements for data, such as results. 
30 A space itself is a service. Like any service, a space has an advertisement, which a client of tiie space must 

first obtam in order to be able to run that space service. A space's own advertisement may include an XML schema, 
a credential or credentials, and a URI which indicate how to access the space. A client may construct a gate fi^om a 
space service's advertisetrient in order to access tiie space, A cUent of a space m^ itself be a service provider 
seeking to advertise in tiiat. space or modify an existing advertisement Or a client of a space may be an application 
35 seeking to access a service or content listed by tiie space. Thus, spaces may provide catalysts for the interaction 
between clients and services m tiie distributed computing aiwonment 

A space may be a collection of named advertisements. In one embodiment, naming an advertisement is tiie 
. process of associating a name string with an advertisement The association may take place upon stormg an 
advCTtisement in a space. Removing an advertisement from a space disassoci^ the name from tiie advertisement 
40 A space may be created witii a smgle root advertisement that describes tiie space itself Additional advertisements 
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may be added to a space. An advertisemenfs name may locate the advertisement within the space, including 
specifying any necessaiy graphing information such as a hierarchy of names. In a preferred embodiment, the . 
distributed computing environment , does not dictate the structure of a space. That is, spaces may be structured as, 
for example, a flat un-related set of advertisements or a graph of related advertisements (e.g. commercial database), 
5 Since, in a preferred enibodiment, the distributed computing environment does not dictate how a space actually 
stores its coatent, spaces may be supported by small to large devices^ For example, a smiple space may be tailored 
to fit on small devices, such as PDAs! More advanced spaces may be mq)lemented on large severs employmg la^^ 
commercial databases. 

As mentioned above, a space may contain advertisements for services in the distributed computing 
10 environment An advertisement may provide a mechanism for addressing and accessing services and/or content 
within ibG distributed computing environment An advertisement may spedfy a URI for a service. In some 
embodiments, the X3M may allow for the service to be accessible over ^e Internet An adveartisement maty also 
include an XML schema for the sendee. The XML schema may specify a set of messages that clients of the service 
may send to the service to invoke fonctionaHty of the service. The XML schema may define the client-service 
1 5 mterfece. Together, the URI and the XML specified in an advertisement may mdicate how to address and access the 
service. Both the URI and schema may be pn)vided in XML as an advotisment in a sp^»^ 
addressing and accessing a sCTvice in a distributed computing environment may be publi^ed as an advertisement in 
a space. CHents may discover a space and then looVsip individiial advertisement for services or content 

Figure 16 illustrates advertisement structure accordmg to one embodiment An advertisement 500, like 
20 other XML documents, may include a series of hierarchically arranged elements 502, Each element 502 may 
include its data or additional elements. An element may also have attributes 504. Attributes m^ be name-value 
string paire. Attributes may store meta-data, which may fecilitate describing the data within &e element 

In some embodiments, an advertisement may exist m different distinct states. One such state may be a 
drafted state. In one embodiment, advertisements may initially be constructed in a drafted state that exists outside 
25 the bounds of a space. The creator of an advertisement may construct it m a variety of w^, inchiding usmg an 
XML editor. Access to elements and attributes m tiie drafted state may be at the raw data and meta-data levels using 
any suitable means. Typically, events are not. produced for changes made to advertisements in the drafted state. 
Therefore, die creator of the advertisement may be free to add, change, or delete elements as well as to achieve the 
desired attribute set, and ^en publish the advertisement for the rest of the distributed computing environment to see. 
30 In one embodiment, another possible state for advertisements is a published state. Advertisements m^ 

move to the published state when mserted into a space. Once the advertisement is in a space, interested clients, and 
senices may locate it, e.g. using its name and/or its elements as search criteria. For example, search criteria may be 
specified as an XMDL template document that may be con^ared (e.g. by the space service) with the advertisements in 
the space. Published advertisements may represent "on-line" services ready for clients to use. The message address 
35 (URI) of Ae service m^ be stored as an element in the advertisement Advertisements that are removed firom the 
space my transition back to the drafted state where they may be discairded or held. Removal may generate an event 
so interested listeners may be made aware of the change. Message gates are typically created j&om published 
advertisements. . • . * 

In one embodnnent, yet another possible state for advertisements is a persistent archived state. An archival 
40 procedure may turn a live published advertisement into a stream of bytes tiiat may be persistently stored for later 
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reconstruction; Archived advertisements may be sent (e.g. in their raw XML form) from the space to an archival 
service. The URI for an advertisement's arcMval service may be stored as an element m 
may provide a format for storing and retrieving advertisements and representing the state of advertisement elements 
sufficient to reconstruct the advertisement object(s). Advertisements may be stored in other formats as well, 

5 depending on archival service implementation. The process of maldng a published advertisement persistent m^ 
prepare tiie advertisement for the persistent archived state. Persistent advertisements may be stored (e.g. by an 
archival service) for fbture use in a persistent storage location such as a file or a database. A space through the 
archival procedure may enable advertisements to be stored, however the space does not necessarily play a role in 
how persisted advertisement entries are actually stored. How persisted advertisements are stored may be determined 

10 by the advertisemenf s archival service. Typically, no events are generated on behalf of archived advertisements. 
Also, changes imo^ not be aDowed for advertbements m Ae persistent 20?^ 

Advertisements iixay be arcMved and removed or just ardiived. If an advertisement is archived without 
removmg it from the space, the space will store a shadow version of the advertisement Access to an archived 
service may cause the advertisement to ''feuft-in" from its persistent backmg store This feature may 

15 aUow advertisements to be fiUed, from LDAP (Lightweight Directory Access ProtocoO entries for example, on 
demand. 

Figure 17 illustrates one example of advertisement state transitions Aat an advertisement may undergo 
during its lifetime. Fhst, an advertisement may be constructed, as indicated at 1. During construction, tiie 
advertisement is m the drafted state. Then, the advertisement m^ be mserted in a space, as indicted at 2. The 

20 advertisement may be mserted as a published parent. The advertisement is in the pubUshed state after being inserted 
in a space. An event (e.g/ AdvInsertEvent) may be generated y^cn the advertisement is inserted in the space. 
Events are more fully discussed below. The advertisement may be archived and made persisfeiit, as indicated at 3, 
;v^diich may transition the advertisement to the persistent archived state. An advertisement may also be published 
from tiie persistent archive state, as mdicated at 4. An advertisement may be removed from a space arid transition 

25 back to the drafted state, as indicated at 5, An event (e.g: AdvRemoveEvent) may be generated when tiie 
advertisement is removed. 

In one embodiment, the archived, persistent state is not used. In this embodiment, state changes 3 and 4 
also are not used. In this embodiment, an advertisement is either in the drafted state or in the published state. 
Advertisements stored in a space niay have Ihe foUowmg stajidardiz^ 
30 (may be an element), creation date (may be an attribute), modification date (may be an attribute), hnplementation 
service URI (may be an element), and/or persistence archival service URI (may be an element). 

A space itself is typically a service. A space service inay provide the ability to search for advertisements in 
. to space, which niay include searching tiie space by type of adve^ A space service may also provide 

facilities to read advertisements, write (publish) advertisements, and take (remove) advertisements. A space may 
35 . also provide the ability to subscribe for space event notification messages. Some spaces may provide extended 
facilities, such as fecilities to navigate space relationship graph by position; read, write or take adyertisemart 
elements; iWd, write or take advertisement attributes; and subscribe for advertisement event notification messages. 
Space fecilities are described m more detail below. A space's c^abilities are embodied in a space advertisement's 
message schema. From the message schema, space address, and authentication credential, a client message gate may 
40 * be created to access the space and its facilities. 
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Spaces and all advertisements within a space may be addressed using URIs. In one embodiment space and 
advertisement names may follow URL naming conventions. The use of URIs, e.g. URLs, for addressing spaces may 
allow spaces to be addressable throughout the Internet, in some embodiments. 

The space message recipient (a space service) may be specified using a URI which may have been received 
ia a service advertisement for the space. The URI may include a protocol, host, port number, and name. The 
protocol may name the protocol that may be used to move messages between clients and the space (reliable or 
un-reliable sockets, for example). The host and port number may be protocol dependent IDs. The name may be the 
space name followed by advertisement, element and/or attribute name. In one embodiment, a pathname may be 
used to identify an advertisement in a space. Patimames may be either absolute or relative. Absohite pathnames 
name the space as well as an advertisement Relative pathnames are relative a designated advertisement yviUm an 
assumed space. In one embodiment, the syntax rules goyenmig the construction of pathnames is that of the URI 
(Unifomi Resource Identifier). In that embodiment, advertisement and space names therefore mjQr not contain my 
URI reserved characters or sequences of characters. Pathnames to elements and attributes may also be specified 
using a URI. In general, element and attribute names may be 25)pended to the pathjoame of an advertisement, such 
as: 

http:/)5avaLSUii.coin/spacename/advertisement/element/attribute. • 
In one embodiment, the distributed computing eoviroimient may include a mechanism that allows a client 
to discover tiie URI of a space but restricts access to the service advertisement for the space. In one embodiment, 
rather than returning the full advertisement to the space, the URI of the space and the URI of an authentication 
service for the space may be returned. In order for the client to access the documents or services advertised in the 
space, the client first may authenticate itself to the authentication service at the URI provided in the return message. 
The authentication service may then return an authentication credential that may allow the client partial or fiill 
access to the space. When the chent receives the authentication credential, the client may attempt to coimect to the 
space to access the documents or service advertisements in the space. 

The distributed computing enviroimient may provide a mechanism or mechanisms that m^ enable a client 
to connect to a space. Embodiments of a connection mechanism may provide for client-space addressing* client 
authorization, security, leasing, client capabilities determination, and client-space connection management A 
client-space coimection may be referred to as a session. In one embodiment, a session may be assigned a unique 
session identification number (session ID). The session ID m^ uniquely identify a client-space connection. In one 
embodiment, a session lease mechanism may be used to transparently garbage collect the session if the client does 
not renew the lease. 

The following is an example of using such a coimection iaoLechanism according to one embodiment A 
client may obtain an authentication credential. In one embodiment, the space may provide an authentication service 
m response to a client's request for access to the space. The client may obtain the authentication credexitial dirough 
the authentication service. When the client receives the authentication credential, the client may initiate a 
connection to the space by sending a connection request inessage. In one embodiment, tiie connection request 
message may include the URI address of the space service, the authentication credential for the client and 
information about the coimection lease the client is requesting. After the space receives the cormectibn request 
message, the space may validate the message. In one embodiment, an XML schema may be used to validate the 
message. The client may then be authenticated using the authentication credentiaL In one embodiment, the 
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infonnation received in the connection request message may be used to detennine the capabilities of the client to use 
the space. In one embodiment, each client of a space may be assigned its own set of capabilities for using the space. 
In one embodiment, an access control Ust (ACL) that may mclude capability infonnation about one or more clients 
of the space may be used in client capabilities detennination. In one embodiment, the infonnation received in the 
5 connection request message may be used to look up the client's capabiMes in tiie ACL. 

After authenticating the client and determining the client's capabilities, the connection lease to grant the 
client may be detennined. After the lease is deteraiined, the structure for maintaining tiie client-space connection 
may be generated. A session ID for the connection may be generated. In one embodiment, each client-space 
connection may be assigned a unique session ID. In one embodiment, an activation space, may be created and 
10 assigned to, or ahematively a pre-existing activation space may be assigned to, the cliait-space session. In one 
embodiment, an activation space m^ be used to store results of services for ^e client Incme 
embodiment, a client's capabilities may be used to detemme if an activation space is to be created for Ae client 
For example, a client may not have capabilities to access an activation space to store and retrieve residts. A message 
or messages may be sent to the client informing the client that the connection has been established. The message or 
15 messages may mchide the session ID and infonnation about the lease. The client may then use the space including, 
but not limited to: advertisement lookup, advertisement registering, and advertisemait retrieval. In one 
embodiment, he connection may remain open until tiiie allocated lease expires or until Ae client sends a mess^c 
requesting lease cancellation to the space. In one embodiment, Ae client may be responsible for renewing the lease 
before the lease expires. If the lease expires before the client renews the lease, the connection may be dropped, 
20 causing the client to lose the connection to the space. In one embodiment, to reconnect, Ac client may be required 
to repeat the connection prdcediire. 

Ltt one embodiment, a client of a space may obtain a space's advertisement several different ways. Some of 
the ways a client may obtain a space's advertisement are iUustrated in Figure 18. For example, a space discovery 
protocol may be provided as part of the distributed computing environment Space discovery is a protocol a client 
25 or service may use to find a space. A listener agent 202 may be configured associated with one or more spaces to 
listen for discovery requests. The discovery listener agent 202 may listen on various network interfeces, and may 
receive either broadcast requests or unicast requests (at tiie URI of tiie agent) from clients 200a looking for a 
space(s). The listener agent 202 then responds with the service advertisement(s) or URIs for the service 
advertisements of tiie requested space(s). hi one embodiment, tiie listener agent is, m general, separate from the 
30 space, because its fimctionality is orthogonal to the fimctionality of a space service. However, tiie listener agent 
may be implemented on the same device or a different device as a space service. 

In one embodiment, the discovery protocol may be a service advertised in a default space. A client may 
instantiate tiie discovery protocol from the client's default space in order to discover additional spaces. The 
discovery protocol may be pre-regLstered witii a client's default space. Alternatively, tiie discovery protocol may 
3 5 register itself witii tiie defeult space by placing an advertisement in tiiat space, e.g., when a client coimects to a local 
network serviced by the discovery service. 

In one embodiment, the space discovery protocol may be UMipped to underl>ing dev^^ 
for otiier platfonns, such as SLP, Jini, UPnP, etc. Ibus, a cHent may use tiie discovery protocol of tiie distributed 
computing environment to find services in other environments. . A bridge to tiiese otiier environments may be 
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provided, and advertisements provided to services in these other environments so that clients of the distributed 
computing environment described hwein may access them. Refer to the Bridging section. 

For each advertised discovery protocol, the distributed computing environment may create a subsequent 
results space to hold the results of the discovery protocol, hi one embodiment, space services m the distributed 
computing environment may use the Multicast Announcement Protocol (multicast UDP) to announce themselves on 
a LAN. A listener agent may record this infonnation. A device (either a cUent or service) may use tiie Multicast 
Request Protocol (multicast UDP) to initiate discovery of a space manager. In one embodiment, the space managers 
. respond with Moimatioh indicating die URI of their re^ Alternatively, a listener agent may respond : 

for multiple spaces. The discovery response may also mclude a short string that labels the each space (e.g. obtained 
&om keywords of the space), and information that can be used to set up a TCP connection, for example, with each 
space manager to perform operations on the respective space. Since the requestmg device may receive responses 
from more than one space manager (or multiple space listings fiom a listener ag^t), this mformatioii may help tiie 
client select viiich space it wishes to coimect to. 

In addition to the miiticast discovery described above, the discovery service may also perform discovery 
using unicast messaging (e.g. over TCP) that can be used to discover a space manager at a known address on tfie 
network (e.g. the hitemet, other WAN, LAN, etc). The unicast discovery message may include a request for a space 
service at a known URI to iHx>vide its service advertisement The multicast and unicast discovery protocols are 
defined at Ae message level, and Aus may be used regardless of whether the devices participating in die discovery 
support Java or any other particular language. 

.The discovery protocol may fecUitate the proliferation of cHents mdependentty of the proliferation of 
server content Aat supports those cUents withm the distributed computmg environment For example, a mobile 
cUent may have its mitial defeult space buflt into its local platform, hi addition to local services advertised m the 
defauh space, the mobile cHent may have services that search for additional spaces, such as a service to access the 
discovery protocol or a service to access space search engines. 
15 hi one embodunent, the distributed computing environment space discov^y protocol may define a set of 

XML messages and Iheir responses that may allow cUents to: 

Broadcast protocol-defined space discovery messages on their netwoilc interfaces. 

• Receive from Hsteners XML messages describmg candidate spaces that those listeners 
represent 

30 • iSelect one of fliose discovered spaces as defeult, without tiie chent needmg to know the 

address of the selected space. 

• Obtain information on deselected space, such as its address, so the cUent may later find tha^ 

same space via means outside of the. discovery protocol (usefiil if later the client wants to 
access a space whi(^ is no loiiger local, but which stiU is of interest to die cHen^ 
35 In some embodiments, die multicast and unicast discovery protocols may require an 

tiiese discovery protocols meet the needs of devices that are IP network are many devices tiiat may 

not be directly supported by these discovery protocols. To meet the needs of such devices in discovering spaces m 
the distributed computing environment, a pre-discovery protocol may used to find an IP network enable agent The 
" pre-discovery protocol m^ inchide the device sendmg a message on a non-IP network interfece requesting a 
40 network agent The network agent may set up a connection between itself and die device. Once die connection 
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between device and agent is set up. the agent participates mthe discovery protocol on IP networks onbehalf of the 
device for which: it serves as , agent The network agent may ako provide an inteifece for the device to the . 
distributed computing environment in general For example, gates may be constructed in the agent on behalf of the . 
device for running services advertised in discovered spaces. See 4e Bridging section. 
5 Mother way that clients may locate spaces in the (BstnWd computing envi^ 

a space.in another space. A space is a service, thereforeso. like any other service, it can be advertised.in another 
space. As shown in Figure 1 8. a cUent 200b may find an advertisement 206 in a first space 204a for a second space 
. 204b. Space 204b may in turn include advertisements to additional spaces. Because a service (implementing a: 
space) may also act as a client, spaces may exchange advertisements or chain together to provide a federation of 
10 spaces, as illustrated in Figure 19. Any number of spaces may be included in the distributed computing 
enviromnent Hie nmnbcr and topology of spaces ms^ be impleine^itetion dependent For example, spaces 
inq)lemented on an IP network nri^t each correspond to adifferoit sutaet 

AlhirdwayadientmaylocateaspaceisthnBUghrunningaservice208.asshownmFi^ Aservice 
208 may be run which returns as its results the service advertisements of space services. Since service 
15 advertisements are XML documents and since the distributed computing enviromnent may inctade the Internet, 
service 208 may be a Web4)ased seaK^i tool An example of such a service is the space \o6k-vp service described 
in conjunction with Figure 4. In one embodiment, spaces wiflun the distributed computing enviromnent may be 
implemented as Web pages. Each Web page space may include a keyword that may be searched iqm to identify 
the Web page as a space in the distributed computing enviromnent Tlie space may mclude other searchable 
20 keywords as well to further define the space. A cUent may comiect to a sesuch service 208 and supply keywords, to 
the search service in the form of XML messages. Hie search service may receive the keywords from the client and 
feed the keywords to an Intemet search engine, which may be a conventional or third-party search engine. Hie 
search service may return the results from the Intemet search engine to fte cUent. either directly as XML messages 
or by reference to a results space. Hie results may be the URIs of spaces matching the search request 
25 Alternatively, the search service may contact spaces identified by the search, obtain the service advertisement for 
each such space, and return the space service advertisements to the cUent, either dnectly as XML messages or by 
reference to a results space. Hie cUent may then select a space from the search results and construct agate (by itself 
orthroughaproxy)to accesstheselectedspace. Once the selected space is accessed, the cUent may look service 
advertisements within that space, which may lead to additional spaces. 
30 As described above, a space may be an XMI^ased Website, and as such may be searched 

Web search mechanisms. A space may include Intemet searchable keywords. Some devices, such as small cli«it 
devices, may not support an hitemet browser. However, such devices may stiU perform hitemet searches for spaces 
. within the distributed computing enviromnent A device may have a program that accepts strings of keywords, 
wUch may be sent to a proxy program on a server (e.g. a search service). Hie proxy may send the strings to a 
35 browser-based seardifiiciUty(e.g. an intemet search feciUty) to perform theses Hie proxy may receive the 
ou^ut of die search and pai«» it into strings (e.g. XML strings) representing each 

send the response strings back to the client Hius. a cUent may lo«.te spaces through the Intemet widiout having to 
support a program such as a Web browser! More capable devices may avoid the use of a proxy and initiate an 
Internet-based search service dfrectly. 
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A fourth way a client may locate a space is by obtaining or receiving infonnation aboirt a newly created 
empty space or a spawned space when an existing space is spawned. An existing space include an interface for 
spawning ah empty space with the same functionality (e.g. same XML schema) as the space from v/inch it is 
spawned. Spawning of spaces is further described below. 
5 Once a client of a space finds the advertisement of a space service, that client of the space may nm the 

space service, as it would any other service. Note that the client of the space service xaay be another service (e.g. a 
service seeking to advertise in the space). In one embodiment, as illustrated in Figure 20, to nm a space service, the 
client of the space may j5rst run an authentication service for the space to obtahi an authentication credential, as 
indicated at 300. The authentication service may be specified in the service advertisement of the space service, llie 
10 client of the space uses the authentication credential, tibie XML schema of the space (from space's service 
. advertisement), and tiie URI of the space (fit)m space's service advertisement) to construct a gate for the space, as 
indicated at 302. The client of tiae space may then nm die space service by using the gate to send messages to tihie 
space service. A first such message is indicated at 304. 

For embodiments employing authentication, when the space service receives the first message from the 
15 client, with the authentication credential embedded, the space service uses the same authentication service (specified 
in the service advertisement of the space service) to authenticate the client, tiius establishing its identity, as indicated 
at 306. The space service may determine the clients capabilities and bind tiiem to the authentication credential, as 
indicated at 308. 

As indicated at 3 10, a client of a space may run various space fecilities by sendmg messages to the space 
20 service- In one embodiment, when a client of a space sends a request to die space service, it passes its auflientication 
credential in that request, so the space service can check the request against the client's specific capabilities. 

Each space is typically a service and may have an XML scheina defining the core fimctionality of the space 
service. The XML schema msy specify the client interfece to the space service. In one embodiment, all space 
services may provide a base-level of space-related messages. The base-level space functionality may be the basic 
25 space fimctionality that is capable of being used by most clients, including small devices such as PDAs. It may be 
desirable to provide for additional fimctionality, e.g. for more advanced clients. Extensions to the base-level space 
may be accomplished by adding more messages to the XML schema that advertises the space. For example, in one 
embodunent, the base-level messages do not impose any relationship gr^h i^n the advertisements. Messages, for 
example, to traverse a hierarchy of advertisernents may be a space extension. Such additional functionality may be 
30 provided through one or more extended XML space schemas or schema extensions for a space. The extended 
schemas may mclude the base schema so that clients of an extended space may still access the space as a base space. 
In one embodiment, a base space service may provide a transient repository of XML documents (e.g. 
: advertisements of services, results of running services). However, a base space service in one embodiment may not 
provide for advanced fecilities to support persistence of space content, navigation pr creation of space structure (e.g. 
35 hierarchy), and a transactional model, A mechanism for supporting persistence, hierarchy, and/or transactions is by 
. extending the XML schema. Since extended spaces stiH include the base XML schema, cUents may still treat 
extended spaces as base spaces, when just the base space functionality is all that is need or all that can be supported. 

In one embodunent, the base space may be transient Hie base .space may be acceptable for many 
purposes. Service providers may register their sendees m various spaces. In one embodiment, services must 
40 continuously renew leases on the publishing of information in the spaces. By this nature, the services 



48 



wo 01/86394 PCT/US0iyi5134 

advertisements may be transient in that they may often be rebmlt and/or reconfiimed. However, it may be desirable 
to provide for some persistence in a space. For example, a space tiiat has results may provide some persistence for 
users that want to be sure that results are hot lost for some tune. In one embodiment, persistence may be provided 
for by specifying a space interface where the client may control which objects in the space are backed by a persistent 
5 store and manage the maintenance of tiiat persistence store. The persistence iriterfece may be specified with 
extended XML schema for the space defining the interfeces for persistence. 

In one embodiment, a base space provide an interfece where an XML document be added to a 
space and identified by a string. The base space may not provide any hierarchy for the various so named XML 
documents m the space. In embodhnents where hierarchy support is desired, additional interfeces may be defined 
10 (extending the XML schema) where the user can specify a hierarchy. Other interfeces may be specified to navigate 
the hierarchy or navigate a relationshq) gr^h by position. Howevw, dher users still use the base space 
mterfeces to access those same documents, without any hierarchy. Interfeces for o&er space structure may be 
provided for as well in extended space schemas. 

Extended XML space interfaces may also be provided for space transaction models. For example, an 
15 extended space XML schema may be provided specifying an interfece for ACID transactions. AGID is an acronym 
used to describe four properties of an enterprise-level transaction. ACID stands for Atomicity, Consistency, 
Isolation, and Durability. Atomicity means that a transaction should be done or undone completely. In the event of 
a feilure, all operations and procedures should be undone, and all data should roUbaclc to its previous state. 
Consistency means that a transaction should transform a system from one consistent state to anotiier consistent state. 
20 Isolation means tiiat each transaction should happen mdepend^itiy of otiier transactions occurring at the same tinie. 
DurabiUty means tiiat completed transactions should remain permanent, e.g. even during system faihnre, Otiier 
transaction models may also be specified in extended space schemas. 

Extended space schemas may be XML documents that specify the message interfece (e.g. XML messages) 
for using extended space features, fimctionality or fecilities. A space may have a base schema and muWple 
25 extended schemas. This may fecUitate provided different levels of service to different clients depending upon tiie 
client authentication. 

Besides extensions for space persistence, structure, and transactions, other space ext^ions may also be 
specified as desired. For example, extensions may be provided to manipulate advertisements at tiie element or 
attribute level: read, write or take advertisement elements; read, write or take advertisement attributes; and subscribe 
30 for advertisement event notification messages. A space may provide virtually any number of fecihties and arrange 
tiiem in base and extended schemas as desired. In one embodiment, all base spaces must provide for advertisement 
reading, writing, taking, and lookup fecilities, and space event subscriptions. 

Various space facilities may be provided, hi. some embodhnents, a facility may be provided for tiie 
establishment of a session with die space. In one such embodiment, the rest of tiie space functionality is not 
35 available until tiiis is done. In otiier embodiments, tiie notion of a session is not provided for, or is optional and/or 
implementation dependent , 

Anotiier space facility may be to add or remove a service advertisement to or firom the space. A space 
facility may also be provided for addmg or removmg an XML document (not an advertisement, but peihaps a result 
" in a space). The space service m^ check for uniqueness of an item before aUowing tiie addition of ti^^ For 
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example, each item added to the space may be associated with a user-specified string that identifies the item and that 
may be used to check for the miiqueness of the item. 

In one embodiment, a client may request a listing, tree or other representation of all services advertised in 
the space. The user then may scroU or maneuver through the advertisements and select the desired service. A space 
5 may also provide a look-up facility that allows a client to search for a service by providmg keywords or string 
names. In one embodiment, a space fecility may provide a mechanism to look up a space entry that has been added 
to the space. The look up facility may search by string to match for name, or wfldcard, or even database query. The 
look up facility may return multiple entries jfrom which the client may select one or perform' a further narrowing: 
search. In one embodiment, the look-up facility may provide a mechanism to locate a service advertisement 
10 matching a particular XML schema. The client may indicate a particular XML schema, or part of a particular XML, 
to be searched for within the space. Thus, a service may be searched for within a space accwding to its interfece 
functionality. 

Another space facility that may be provided in the distributed computing environment is a mechanism that 
allows services and clients to find transient documents based upon a typing model such as XML. The mechanism 
15 may be a general-purpose, typed document lookup mechanism. In one embodiment, the lookup mechanism may be 
based upon XML. The lookup mechanism may allow clients and services to find documents in general, inchitog 
services throu^ service advertisements. 

In one embodiment, a space lookup and response message pair may be used to allow clients and services to 
find XML docuinents stored within a network transient document store (space). The space may be a document 
20 space used to store a variety of documents. In one embodhnent, die documents are XML documents or nonrXML 
documents encapsulated in XML. Spaces are fiather described elsewhere herein. The lookup messages may. work 
on any kind of XML document stored in the space, including service advertisements and device driver 
advertisements. In one embodiment, a cHent (which may be another service) may use a discovery mechanism as 
described elsewhere to find one or more document spaces. Then, the cUent may use space lookup messages to 
25 locate documents stored in the space. 

The distributed computing environment may. include a mechanism that allows services and clients to 
subscribe to and receive events about the publication of XML documents. Events may include the publication of 
and removal of XML documents to and from a transient XML document repository such as a space. In one 
embodiment, an event may be an XML document that refers to another XML document 
30 In one embodiment, a space event subscription and response inessage pair may. be used to aDow clients and 

services to subscribe for events regarding documents that are added to or removed from a space. In one 
embodiment, an event subscription may be leased using the leasing mechanisms described elsewhere herein. In one 
embodiment, a subscription may be cancelled when the lease is cancelled or expires. In one embodiment, renewing 
the lease to the subscription may renew a subscriptiorL 
35 In one embodiment, an event subscription message may include an XML schema that m^ be used as a 

document matching mechanism. Documents that match the schema inay be covered by the subscription. In one 
embodiment, any document added to a space and that matches the XML schema inay generate a space event 

naessage. . • 

A space facility may also be provided to which a client may register (or unregister) to obtam notification 
40 wiien something is added to or removed firom the space. A space may contain transient content, reflecting services 
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tbat at added and removed from the space. A mechanism may be provided to notify a client whea a service becomes 
available or becomes unavailable, for example: A client may register with an event service to obtain such 
notification. In one embodiment, a , client may re^ster to .be notified yfbm a service having a name matching a 
specified string or a schema matching a specified schema (or schema portion) is added or deleted from the space. 
5 Thus, a query to register with the.space event notification facility m^ be the same as or similar to that of the service 
look up facility described above. 

When a client of a space subscribes to be notified whai an XML document(s) (e.g. service advertisement) 
is added or removed from the space, the client may obtain a lease on this subscription to . notifications. The lease 
may allow the space service to know whether to continue sending notifications to a particular client For exaniple, a 
10 lease to the notification facility m^ expire after an amount of time if not renewed. Note that a lease may hot be 
required while a client has established an active session with a space. Chice, a client has discontinued an active 
session with a space, the client may continue to receive event notifications according to its event subscriptions as 
long as hs corresponding leases remain active. Refer to the Leases secticm below. 

A client may subscribe to different types of events. Examples are a service advertisement being added or 
15 removed from a space, as described above. A cHent may also be notified when results from a service initiated by the 
client (or by someone else) are put in a space. For example, the client and the service may mutually select a name 
for refenring to the results of the service. The client may register widi the space service to which the results are to be 
posted or advertised to receive an event when a result referenced by the selected name is added to tiie space. 

A space may generate different types of events to which a client may subscribe. As die composition of a 
20 space changes, events may be produced to those clients and services that have subscribed for such events. In one 
embodiment, there may be two major space event categories, those that pertain to tfie space (insertion and removal 
of advertisements), and those used that indicate changes to an advertisement (adding, removing, changmg an 
element or attribute). Which events are supported may be indicated m the XML message schema for die space. 

The followmg events are exan]4)les of events that may be produced by a space service to indicate a space or 
25 advertisement event 

Table 1 



Space Events . 



Event Name 


Type 


Meaning 


Advertisement 
Insertion Event 


AdvInsertEvent 


New advertisement has been inserted 
into a space 


Advertisement 
Removal Event 


AdvRemoveEvent 


Existing advertisement has been 
removed from a space 


Advertisement 
Element Insertion Event 


AdvElementlnsertEvent 


A new element has been added to an 
advertisement . 


Advertisement 
Element Removal Event 


AdvElementRemoveEvent 


Existing element has been removed 
from an advertisement 


Advertisement 
Element Change Event 


AdvElementChangeEvent 


Existing element has been changed in 
an advertisement 
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Advertisement Element 
Attribute Insertion Event . 


AdvElementAttributelnsert 
Event 


A new attribute has been added to an 
element 


Advertisement Element 
Attribute Removal Event 


AdvJblemenuVtinDuieivemove 
Event 


firom an element 


Advertisement Element 
Attribute Change Event 


AdvElementAttributeChange 
Event 


Existing iattribute has been changed in 
an element 



Events may be typed. In some embodiments, the event fecilities supported by spaces may allow for event . 
listeners to take advantage of, e,g., Java class (or XML types) hierarchies. For example, by listening for 
AdvElementEvent, the listener will receive events of type AdvElementEvent and all of its sub-classes (XML types). 
Thus, for this example all events pertaimng to element changes (though not advertisement insertion and removal) are 
received. 

By v«iy of ftirther example, subscribing to or listening for a top-level event class or type, e.g. SpaceEvent, 
will result in the reception of all space events. Event class ^pes may be distinguished via, for example, the Java 
/M5/awceq/"operator or the XML typing system, 

An event include a URI to the affected advertisement or element For example, AdvertisementEvent 
and.all its sub-classes may contain a reference (e.g. URI or URL) to the affected advertisement AdvEliementEvent 
and its subclasses may be examined for the name of tiie affected element Hie previous element value (URI or 
URL), may be available, for example, from AdvElementRemoveEvent and AdvElementVahieChangeEvent 

A space event type hierarchy for one embodiment is illustrated in Figure 2L Types may be defined in XML 
and usable in Java or any other suitable object-oriented language such as C++. 

A space may provide a facility for a client to instantiate a service advertised in the space. Service 
instantiation is the initialization done that allows a client to be able to run a service. On embodiment of service 
instantiation is illustrated in Figure 22. To instantiate a service, a client first select one of the service 
advertisements published in the space, as indicated at 320. The client may use the various fecilities, such as the look 
up fecility, provided by the space to look up the varioxis advertisements in the space. Then the client may request the 
space to instantiate the service, as indicated at 322, 

In one embodiment, service instantiation may include the following actions. After the client requests tiie 
space service to instantiate the selected service, as indicated at 322, the space service may then verify the client is 
allowed to instzuatiate the requested service, as indicated at 324. The space service may perform this verification by 
examining an authentication credential included in the client's message. The . authentication credential is tiie 
credeintial the client received when it established a session with tiie space service. The space service may verify if 
the client is allowed to instantiate the requested service according to the client's authentication credential and 
capabilities indicated for that client See the Authentication and Security section herein. 

Assuming the cUent is authorized, the space service may also obtain a lease on the service advertisement 
for the client with the lease request time specified by the client, as indicated at 326. Leases are further discussed 
below. The space service may tiien send a message to the client which mchides the allocated lease and die sendee 
• advertisement of the service, as indicated at 328. in one embodiment, the client may run an authentication service 
specified in tiie service advertisement and obtain an authentication credential, as indicated at 330. See the 
Authentication and Security section herein for more information on an authentication service. Next, as indicated at 
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332, the client may construct a gate for the service (for example, using the authentication credential and the XML 
schema and service URI from the advertisement). Refer to the Gates section herein. The above described 
communication between the client and space service is performed using the XML messaging of the distributed . 
computing environment The cUent may then run the service using the constiucted gate and XML messaging. The 
5 service may similarly construct a sen^ice gate for XML message conunim^ 

To summarize, an example use of a space is discussed as foUows. A cHent may access (e.g^ connect to) a 
space service. (A service may act as a client for the purpose of accessing or otherwise usmg a space.) The space 
. service may store one or more service advertisements and/or other content in a space^ and each of the service 
advertisements may inchide information which is usable to access and execute a corresponding service. The space 
10 service may inchide a schema whidi specifics one or more messages usable to invoke fimctions of the space service. 
For example, the schema may specify methods for reading advertisemaits from die space and publishing 
advertisements in the space. The schema and service advertisements be expressed i^. an 
language such as extensible Marioip Language (XML), In accessing the space service, the client may send 
information such as an XML message (as specified in the schema) to the space service at an Internet address. In 
15 accessing die space service, the cfient may search the one or more service advertisements stored in the space. The 
client may select one of the service advertisements fit)m die space. In one onbodiment, the client m^ s«id an 
instantiation request to die space after selecting die desi^ A leasem^be 

obtained for die desired service, and die lease and die selected service advertisement may be sent by die space 
service to die cUent TTie cUent may dien construct a gate for access to die desired service. Hie desired service may 
20 be executed on behalf of the client 

Anodier facility provided by a space service may be die spawning or creation of an empty space. This 
space faculty may allow a client (which may be a service to another cUent) to dynamicaUy create a new space: In 
one embodiment, diis space fecility may mclude an interfece for spawning an empty space widi die same 
fimctionality (same XML schema or extended schema) as die space fiom which it is spawned. This fecility may be 
25 usefid for generating (e.g. dynamical^ spaces for results. For example, a cUent may spawn a spaed a reqoest a 
service to place results or advertise results in die spawned space. TTie cfient may pass die spawned space URI 
- and/or audientication credential to die service. Or a service may spawn a space for results and pass die spawned 
space URI and/or audientication credential to die client In some embodiments, once a space is spawned, it xnay be 
discovered just like odier spaces using one or more of die space discovery mechanisms described herein. 
30 By using a mechanism in which a space m^ be created via an interfece in anodier space (e.g. a space 

spawning facifity), new spaces may be created efficiently. For exauqile, in one embodiment, storage for the 
spawned space may be aUocated using die same faciUty used by die original sp^ Also, a spawned 

. space may share a common service facility witii its original (or parent) space. For example, a new URI be 
assigned to die new space. In one embodiment, the new URI may be a redirection to a common space fecility shared 
35. widi die original space. Tlius, a newly spawned space my use die same or some of die same service code as diat of 

the original space. 

Space faciUties may also include security administration, for example, to update die various security 
poHcies of die space, and odier administrative fecUities. For example, die.number and age of advertisements may be 
controlled and monitored by a root space service. Old advertisements may be collected and disposed. See, .e.g., die 
40 Leases section herein for when an advertisement may be considered old. The service implementing die space n^ 
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10 



be under the control of an administrator. The administrator may set poUcy in a service dependent manner. Space 
fecilities may also include a fecility to delete an empty space. 

Certain spaces may include feciUties or services to fiirther support Ae proltferation of certain cUents, such 
as mobile clients. For example, services in spaces that a mobile client may discover, e.g. via the discovery protocol, 

rnay provide support for mobile clients, such as: 

• Assigning and admmistering temporary network addresses for the clieii^ 

Proxying message passing for the client . . 

Providing search facilities for additional spaces. For example, a service may allow a 
client to specify keywords through a simple mterface. The service then uses the keywords in 
conjunction with Web search en^es to search for spaces on the Web, as fimher descrTbed 
herein. In other embodiments, a seardi service may constrain clients to searching only a few 
supported spaces within the distributed conq)utiiig environment 
As mentioned earlier (see Figure 9 and accompanying text), spaces may provide a convement mechanism 
for storing results from a service run by a client Using a space for results may allow a small cUent to receive in 
15 pieces the results of running a service. Some services may generate a large amount of results. By usmg a space to 
store the results from a service, clients that do not have Ae resources to receive the fiiU results at once may still use 
Hie service. Moreover, by using a space to store results, a service rinming on a fest busy sa^ 
interacting directly with a slow client when retumh^ large results. Thus, the service may be freed sooner for use by 
other clients. 

20 A space may provide a convenient mechanism for accessing a result by different clients a^^ 

times. For example, a client may not be able to use the entire result, but a user may want to access the rest of the 
' resuU later using another client that can access it For example, the result could be stock quote information, showing 
the current price of a stock (accessible by a PDA), and showing a chart of stock prices (accessible by a laptop later). 
. Also, using a space in the distributed conq>uting environment for results may aUow a cUent to feed the result of one 
25 service into another service, without the necessity of downloadmg the re^^ For example, in the case of tiie 
stock quote, information above, the PDA could feed the chart into another service, which prints tiie chart, without the 
PDA having to download tiie chart itself Thus, a results space may provide a mechanism for a client to pass to 
another chent or service wdtiiout tiie client havirig to handle or receive flie results. 

In different embodiments, the decision to use a space for results m^ be mandated by the service, mandated 
by the cUrat, and/or requested by the client A service m^ suggest the use of a space for its results, e.g., m its 
advertisement In one embodiment, either the cHent or the service may spawn a new space for results or use an 
existing space for results. See the description herein regarding spawning spaces. 

In one embodiment, the use of a space for results does not necessarily mean that the service must put all 
. r^ts in that space. Tbere may be alternatives for any result a service generates. For example, part or aU of tii 
35 result may be sent in-line in a message to the cUent Alternatively, the result may be put in the space, and then a 
notification message may be sent to cUent, referencing the result (e.g. mcluding a URI to the result or to an 
advertisement for the result). Another option may be to pm the result in the space, vrith notification via an 
fromdiespace. For exan^le,. the client and the service may agree to. caU the result some particd^ 
the cHent may register with the space (using a space feciUty such as described above) to receive an event when a 
40 result so named is added to the space. See tiie descrq>tion above on event notification. 
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Thus, several differeat mechanians may be employed w 

service to return results to a client The actual results may be retunied to the cUent by value in an XML m 

results may be retimied to the client by reference with the actual results (or advertisement for the actual results) put 

in a space and the client receiving a message referencing the results m the space. Moreover, results, or results 
5 advertisements, may be placed m a space and the client notified by event 

. Another mechanism for handlmg results may be for &e client to specify another service for the results to be 

fed to. For example, when a cUent runs a service that will produce results, the client naay instruct diat service (e.g. 

tiirough XML messaging) to send the results to another service for further processing. This may involve the client 

indicating the UM of an advertisement for the other service so that the r^^^ 
10 to the other service in order to run fho other service and pass it the results. In this example the result-producing 

s^ce m^ be a client of the other service. In some embodiments, tiie cHent m^ send the schema or a pre- 

constnicted gate to the result-pioducmg service to access the service for 

for further processmg is a display service fbat may displ^ the results for the ori^ client This display service 
may be on or associated with the same device as the client 
15 Result spaces and method gates may aUow the distributed computing environment to provide a simple 

remote method invocation that is practical for thin clients wife mmimal memory footprints and minimal bandwidth, 
because it need not have the adverse side effects of huge program objects (al 

(necessarily) across the network to the client as m conventional remote method mvocation techniques. Instead, 
results may be returned to a result space, and only if desired (and if tiiey can reside on the client) are the actual 

20 objects downloaded to the cUent 

The mechanism by which the distributed computing environment may provide for remote method 
invocation is as follows (refer also to the description of method gates in the Gates section herein). An object may be 
advertised (e,g. as a service or as part of a service) in a space. The advertisement includes a reference that contains 
die URI (e.g. URL) of the object, along with other access parameters, such as security credentials and XML schema. 

25 A cUent may have or may construct a cUenf method gate for the object, which for every method of the object (or 
service) itself may have a wrapper method that takes the method parameters and creates a request XML message to 
invoke a metiiod of the object The XML message is sent to a service gate ti^ 

service object When that method returns a result object, the service gate may post the result object in a results 
space, and may retum a message to the client with a reference to tiie result object. 

30 Thus, for a cUent to mvoke a remote mediod, the cUent first sends a message to instantiate an object (e.g. 

service), such as described above. In one embodiment, instantiation of an object may include the creation or 
spawning of a results space. In another embodimer^ results space creation may be independent from the object 
mstantiation. Instantiation may return the object URI to the client, and the cUent and service gates may be 
dynamically created when a client requests mstantiation. hi some embodiments, a results space may aheacfy exist 

35 and be advertised by the object (service). Some part or all of the gates may also have been pre^onstnicted or 
. reused. 

Once a client has initiated an object, a local caU of the appropriate cUent method gate wiU affect a remote 
call to the actual remote object, as described above. The remote metiiod mvocation approach of the distributed 
computing environment may be recursive, with object references returned to the cUent, instead of the objects itself; 
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when the client gate is called Note that such returned objects may already be instantiated. In some embodiments, 
the client may make a decision to download an entire object itself rather than just remotely invoke it 

A method or service invoked as described above may generate a child gate that is associated with the 
results document The method may return a child gate (or the schema, URI and credentials for the client to construct 
5 a child gate) for the references instead of the references themselves. The client may then access the references 
through the child gate. The child gate may also be a mediod gate. 

As described above, this remote method invocation provided by the distributed computing enviroimient 
allows the real result object(s) to be stored in a service results space (^^ich also be created dynamically, by a 
servlet for example). The results space may be temporary. The results space may act as a queiy results cache. The 
10 results cache may be patrolled by server software (garbage collector) tfiat cleans-up old result areas. Distributed 
garbage collectibn may be employed, as result spaces may fill \sp until they are destroyed by a client indicating it no 
longer needs the space, or by an administrator on a server setting appropriate limits. 

Turning now to Figure 23, an illustration of a defeult space 350 is provided. The distributed computing 
environment may provide at least one default space so clients can find an initial set of advertisements. A device may 
15 have a defeult space that exists locally, with a built-in pre-constructed gate. Hie services advertised in that default 
space may exist locally on that device, and they may provide system software that enables or fecilitates the device's 
participation in the distributed computing environment 

The defeult space 350 may include one or inore mechanisms 352 to locate external spaces, as shown in 
Figure 23. One service in the defeult space may run the space discovery protocol described above to find external 
20 spaces. Also, external spaces may be advertised in the default space. Additionally, a service (e.g. a search engine or 
a proxy service to a search engine) may be advertised in the defeult space Aat determines or finds external spaces. 
. Each space may be analogous to a file system moimt point Thus, the distributed computing environment may 
provide searchable, dynamic mount points to services. A defeult space may be a client's initial mount point to the 
distributed computing environment 
25 A defeult space or access to a defeult space may be built in to a device. Through tiie defeult space and 

local services that may exist on the device, a clieint execution environment for the distributed computing 
environment may be provided. A device's local services and defeult space service may have built-in pre-constructed 
gates. One of the built-in services listed in the defeult space may be a service to run the discovery protocol so that 
the client may locate additional (e.g. external) spaces. A defeult space may include a built-in service that provides 
30 an execution environment for clients that allows the client user to browse spaces, select, and then instantiate 
services. Such a service may provide a simple user mterfece that allows a client to entire strings (e.g. keyword for 
space searches), view or browse result references (e.g. space listings, or service listings witiiin a space), select items 
(e.g. to chose and instantiate a service), etc. 

Devices that primarily provide a service may also include a defeult space and may include a built-in service 
35 in the default space that allows a service to manage advertising itself in various spaces. For example, a device, such 
as a printer, may have a built-in default service that finds (perhaps tiirough the discovery protocol) a space on a local 
area network and adds an advertisement for the printer service to that space. This service may also maintain the 
printer service advertisement within the LAN space, for example, by renewing its lease or updating the printer's 
XML schema, etc- 
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For some devices that provide a service, the oveAead of findm 
maintain that advertisement is undesirable. In one embodiment, rafter than searching for and maintaining a space or . 
spaces to publish service advertisements, services on some devices may transmit their advertisements in r^^^ 
connection requests. For example, a printer device with a printer service that is available on a proximity basis may 
,5 not maintain an advertisement m a space (on the device or external to the device). Instead, when another device 
. establishes a connection with the printer device (for example, a user with a laptop ninnmg a cHent desires to print a 
document), the printer service may transmit the service advertisement to provide the XML service schema for 
connecting to and running the service that providw printing functionality on the printer device. Also, some devices 
may only maintain advertisements for their services in a certain vicmity OT 
10 desire to support or may nothave access to transports for broader accessibiUty- 

One example of a service device in whi«ii ft inay be desnable for the deWce to avoid or 1^ 

service advertisements in a space is a device whose fimctionality b available on a proximity basis. Proxfanity-based 
services may provide advertisements of their fimctionalily upon request These advertisements may not be broadly, 
accessible. For example, proxhnity-based services may be provided in a whreless communications system. The torn 
15 "wireless- may refer to a communications, monitoring, or control system in which eiechomapietic or acoustic 
waves cany a signal thit,ugh atmospheric space rather than along a wire. In most wireless systems, radio frequency 
(RF) or mfiaied (IR) waves are used. Typically, in pioximity-based wireless systems, a device compri^ 
transceiver must be withm range (proximity) of another device to establish and maintam a communications chamieL 
A device may be ahub to comiect other devices to a wireless lx)cal Area Network (LAN). 
20 As mentioned, embodhnents of the distributed computing enviromnent may provide a mechanism usbg a 

lookup space that allows clients to rendezvous with services. In a proxhnity computing enviromnent. one 
embodiment of the distributed computing enviromnent may provide a service discovery mechanism that cUents may 
use to discover services witliout usmg lookup spaces as rendezvous points. An example of a proxhnity computing 
environment is an IrDA point-to-point communications enviromnent In a proximity computing enviromnent, the 
25 proxhnity mechanism may find the "physical" location of the service for the client For example, m an IrDA 
enviromnent, the cUent device may be physicaUy pointed at flie device includmg flie service(s) ti^ 

to use, 

Ihe proximity service discovery mechanism may enable tiie cUent to directiy look for service 
advertisements rafter than sendmg a lookup request to a lookup space to look for service , advertisements. Smce the 

30 cUent device may have established a proxhnity comiection to fte service device, fte cUentmay directly request fte 
desired service. For example, a PDA cUent device may establish a proximity connection to a printer device; fte 
cUent niay "teovir to request a prhiter service connection on fte printer device. 

In. one embodiment, fte client may send a proximfty service discovery message to fte service device. The 
message may include mformation fliat may specify a desired service on fte service device to whicft fte client device 

35 has a proxhnity connection. In one embodhnent, a service on the service device may respond to the proxhnity 
serrfce discovery message, and may send to fte cUent fte service advertisement that fte cUent n^ 
the desired service. The prpxhhity service discoyery message may also mclude information that may be used to. 
. auftenticate fte cHent and to. establish fte cUenfs capabiHties on fte service. Using fte received service 
advertisement, fte cUent may establish a gate to establish, communication wift fte desired service. 
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Nevertiieless, it stfll be desirable to publish advertisements for sendees that do not desire to or cannot 
maintam their advertisements in a spice that is broadly accessible. In one embodiment of a distributed computing 
environment, a device that establishes a connection with a .device that does not publish its setVice advertisement(s), 
such as a proximity-based device. m^ publidi service advertisements received from fee non^publishing device. For 
5 example, a device that establishes a connection with a proximity-based device and ftat has an alternate transport 
.connection(s) may publish (or republish) service advertisements received from the proximity-based device in flie 
alternate transport environment, thus aUowing the proximity-based device service(s) to be used by other devices 
(toough fee (re)pubUshed service advertisements) wtoch are outside fee normal proximity la^^^ 

The publishing device may locate a locally pia)lished service advertisement for the proximity^^ 
10- ftrough a discovery and/or lookup service, or alternatively fee service advertisement may not be published by fee 
local serrice device, but instead m^ be sent to fee publishing device by fee local devi^ 
comiection, as described above. In one embodhnent, the republished service advertise 
as long as fee device maintaining fee advertisement is connected to or able to connect to fee local device. For 
example, if fee publishing device is disconnected from fee local device (for ex^ 
15 of fee device), fee service advertisement may be made stale or removed. A lease mechanism may be provided to 
allow the space contaming fee advertisement to send lease renewal messages to fee publidiing device. The 
publishing device may verify its connection to fee local device, feus aUowing fee space to detect 
device is no longer available. Rules for how fee service advertisements are republished may be provided by fee 
local device or by an admimstrative policy for fee local vicmity (e.g. proximity area) or local networic 

20 . Figure 24 illustrates an cKanxple of a device bridging proximity-based devices onto anpfeer transport 

mechanism to allow fee services provided by fee proximity-based devices to be accessed by devices outside fee 
proximity range of fee devices, according to one embodiment A publishing device 1404 may be connected to a 
network 1412. such as an Efeemet LAN or fee hitemet, etc, and may estabUsh and maintain proximity connections 
1414 wife proximity devices 1400 and 1404. Proximity connections may be wireless connections or wired LAN 

21 conuections. for example. Proximity devices 1400 and 1402 may each send a service advertisement to fee 
publishing device 1404 upon connection, or, alternatively, fee publishing device may locate fee service 

. advertisements usmg a discovery and/or lookup service for fee proximity connections. The publishing device 1404 
may feen make fee services provided by the proximity device? available to ofeer devices 1408 and 1410 «» the . 
network 1412 by repubUshing fee service advertisonoits 1416 and 1418 m space 1406. Space 1406 may be stored 
30 . on fee publishing device or on ofeer devices connected to fee LAN (includmg devices 1408 and 1410). 

Ofeer devices on fee LAN including devices 1408 and 1410 may feen discover space 1406 and look the 

rqiublished service advertisements 1416 and 1418 fw fee proximity-based devices, establish gates to communicate 
■■ ' to feose services (device 1404 may act as a proxy or bridge) on fee proximity-based devices 1400 and 1402 using 

fee XML message passing mefeods described previously, and send requests and receive iesuhs to fee proximity 
35 devices. Publishing device 1404 may act as a bridge betwecn.fee network 1412 and fee proximity connections 1414 

to fee proximity-based devices. 

Leases ' ■ 

Leases may be used in fee distributed computing environment to deal wife partial feilure, resource 
40 synchronization (schedulmg). and to provide an oideriy resource clean-up process. Leases may help the overall 
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distributed system manage independent clients and services tiiat may come and go. The various resources that 
clients obtain from services (including space services) may be leased from those services, hi general, hot every, 
resource can or needs to be leased. In one embodiment, it is up to the implementation of each particular service to 
determine which of its resources need to be leased. In particular, resources used by a large amount of clients 
5 simultaneously inay not need leasiiig or instead may require custom leasing protocok. This class of leasing may be . 
left to the service provider. Custom protocols, such as those to implement transactions for example, may be built 
upon the base leasing scheme. In one embodiment, the base leasmg model is a relative time-based modiel. . 

Services may issue leases to clients and provide operations on those leases. In one embodunent, all such 
lease functionality of a service is part of that service's XML schema. Thus, a client may use its gate (corresponding 
10 to the service and constructed for die service's XML schema) to perform lease operations, in one embochment, all 
services that issue leases provide the followmg lease operations (only allowed by the owner of the lease): (i) 
renewing a lease (parameters specified: lease*(e.g. lease ID, lease credential), new lease time requested), and (li) . 
canceling a lease (parameter specified: lease (e.g. lease ID, lease credential)). In one embodiment, all leases are 
granted for a particular amount of relative time (duration of lease) that may be negotiated. The requestor may 
15 specify a cotain amount of time (e.g. m seconds), and tbe grantor may grant the lease for any amount up to that 
time. In one embodiment, a -1 value may be used to specify an indefinite lease. 

In one embodiment, a service advertisement may include one or more leasmg addresses. In one 
embodnnent, the leasmg addresses may be URIs. Standard leasing messages to renew and cancel service resource 
leases may be sent to a leasing Uia. An example lease URI: 
20 <leaser>servicel://resourceKleaser> 

An advertisement may also mclude various leasing messages as described above. Leasing niessages m^ 
include messages to renew and cancel leases for resources of the service. In one enibodiment, the messages may be 
comprised in an XML schema in the advertisement 

The leasing mechanism may provide a mechanism to detect service and client feihire. Leases may also 
25 provide a mechanism to provide shared and exclusive resource access. In one OTibodiment, all service resources 
either have no lease (resource is not leased and therefore available), a shared lease (resource accessed by multiple 
clients), or an exclusive lease (resource is accessed by exactfy one client at a time). In one embodiment, all 
resourt^s beghi in the no lease state. A no lease state signifies ftiere is no current access to the undertying resource, 
and mdicates that there is an interest in the resource remaining in existence and tiius available for leasing. The 
30 leasing level may be increased fi-om none to shared, none to exclusive, or shared to exclusive, Lease isolation levels 
may also be decreased fi:om exclusive to.shared, exclusive to none, and shared to none. In one embodiment, dicnts 
may voluntarily increase or decrease the lease isolation level, or may be requested by the service to do so. A 
response message from the service may indicate if the isolation level change was accepted. 

Request-response message pairs may be employed to claim, release, and renew a lease. Each message may 
35 be tagged using a reserved XML tag to indicate that the message is a leasing message. The distributed computmg 
environment doesn't necessarily define the complete composition of the message. In such an embodiment, service 
. developers may append custom message content, as long as, the message is tagged as a leasmg message. 

In one embodiment, clients that use leased resources ma^y be expected to: (i) claim the resource as shared or 
exclusive, Qi) release the resource claim (if requested or if finished with resource), and (in*) respond' to renewal 
40 messages (with another claim at same or different isolation level). Renewal messages may be sent (e,g. in regular 
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intervals) by. services to detect client feilure cases. The interval (at vMch the renewal message is sent) may be 
service specific. If a response to tiie renewal message isnt issued after a specific amount of time (e.g. based on a 
time noted m the service advertisement), a resource reclamation process may begin within the service, revoking the 
lease completely. In such an embodiment, renewal messages sent to clients should be handled in a timely feshioa. 

5 Figure 25 illustrates the use of renewal messages both between a client and an mstantiated service and between a 
service provider and a space service. Note that both cases may be considered as the use of renewal messages 
between a client and a service, since a sarwce provider may be a client to a space's advertisement service. 

Renewal messages may arrive in an "out of band" fashion that may be inconvenient for the client to handles. 
That is, the client cannot predict when a renewal message will be sent from the service. Out of band message 

10 haridling may complicate the client's logic and increase its complexity. To solve this problem, an automatic lease 
renewal mechanism may be implemented to reHeve tiie cheirt 

mess^es, and Urns reduce client complexity. In tiie automatic lease renewal mechanism, each gate (message, 
method, and/or event gate) rimy receive renewal messages and automatically respond to them without help firan the 
client The default response to a renewal request is to claun the lease at its currwit level Each message gate may 
15 contain a single, set-aside renewal response message that is automatically sent to the advertisement space service 
when the gate receives the renewal message. This **out of band" message is handled on behalf of the client, yielding 
a cleaner client programming model In one embodiment; the gate may allow clients to register lease event haiidlers 
to specify different isolation levek in the response message. 

The leasing mechanism may also provide a mechanism to detect stale advertisements. When a service 
20 publishes its advertisement in a space, that service obtains a lease on this publishing of its advertisement Each 
advertisement may contain a time by which the service promises to renew the advertisement In one embodiment, 
all time-out values are specified in seconds. Kthe service contmues to renew its lease, the space is provided some 
assurance &at the service advertised is still being offered. The renevral time m^ be counted down towards zero by 
the space service. If the service does not renew its lease, the service may have felled, or it may no longer wish to, or 
25 be able to provide the service. When the lease is not renewed, die space service marks the service advertisement 
stale, so it does not make it available to clients. Services renew advertisements by sending a renewal mess^e to the 
space. The space service receives these messages and resets the advertisement renewal time back to its initial value. 

In one embodiment, stale advertisements are not automatically deleted. Depending upon die policies of the 
space, it may choose to delete stale service adveitisements that have eaqpn^ for a reasonably long POT 
30 The deletion policy may be set by the space service. The space service mscy search for stale advertisements and 
either delete them or bring them to the attention of an admiiiistrator, for example. 

A space service may use leases to manage the resources its fecilities provide to clients (including other 
services) of the space. For example, when a client desires to use a service, the space service may request a lease for 
the client as part of service instantiation. Service instantiation may be performed to allow a client to run a service. 
35 To mstantiate a service, a client may first select one of the service advertisements published m a space. The client 
may use die various fecilitiets provided by tiie space to look iq) advertisements in the space. Then the cliipnt may 
request the space to instantiate the service. The lease acqmred during service instantiation is on use of the servic 
advertisement (not the same as the lease on publishing of the service advertisement). It should be noted that the 
' space service may allow multiple clients to have a lease on use of a service advertisement if the advertisement has an 
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indication it is shared Otherwise, the space serviw only aUows one cUerf 
advertisement (exclusive).. 

Another example of how a space service may uses leases to manage Ae resources its fecilities provide to 
clients is when a client of the space registers to be notified when XML documents (e.g. service advertisements) are 

5 . added or removed Jfrom a space. Hie registering cUent of Ihe space may obtain a lease on this subscription to 
notifications- This lease enables the space service to know v^e&er to continue sending notifications. Such a lease 
may not be necessary, when a cUent has established an active session witii the spac^^ Also, note that when a client of 
a space (could be a service) establishes a session with the space, the cUent may obtain a lease on the session. This 
allows the space to manage any resources associated with tiie session. 

10 In another embodiment, die distnT>uted computing enw^ 

nottime-based Theleaseinay be generated whai an object is claimed for use, 
the claim metiiod may accept a callback that notifies die current leaseholds 

same object (e.g. service). Thus, as an alternative embodiment to time-based leases, instead clients may m^e 
claims on space objects (e.g. services). When another client desires a lease that is inconq)atible witii die current 

15 leaseholder's lease, die service may seiid a "callback message" to &e client Upon receiving die callback message, 
the cUeht (Le. cHent gate) may invoke a callback mefiiod to dedde on aresponse to die callback message (keep the 
lease, cancel the lease, change die access level to shared, etc.). Once a response has been determined, die client gate 
sends a response message to die service. This distributed mechanism for maim^ leases may be inqilemented 
using the XML message-passing layer. 

20 For a non-time-based lease embodiment, die distributed computing environment may provide lease support 

for several levels (or kmds) of access diat allow a distributed algoridun to determme lease con^atibility. Those 
levels may include: (i) keep die object in die space (keepInSpace), (ii) read die object in die space (readShared). and 
Qii) read exclusively the object in the space (readExchisive). 

25 Authentication and Security 

The distributed computing environment provides for spontaneous and heterogeneous distributed systems 
based upon an asynchronous message passing model, v^diere data and/or objects may be represented in a 
representation language such as XML. In die distnTiuted computing environment, cHents may connect^ ^ 
tiirougbout die Internet, for example. The distribtited computing envnx)nment luay enable large nmn^ 

30 devices to work togedier in a rehable, dynamic, and secure fashion. The distributed computing environment may 
define a protocol diat substantiaUy enables interoperabiUty between compliant software components (clients and 
services). 

In die context of die distributed computing environment, a device may be a networkmg transport 
addressable unit Clients a^d services m^ be implemented as Universal Resource Identifier (URI) addressable 
35 instances of software or finnware that nm on devices. 

Internet space is inhabited by many points of content A URI is a mediod used to identify any of daose 
pomts of content, whedier it be a page of text, a video or sound cHp, mi image, software, firmware or odier Internet 
content Hie most commori form of URI is die Web page address, viiich is a particular form or subset of URI called 
a-Uniform Resource Locator (URL), A Um typically desaibes die mechanism used to access die resource, 
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specific computer that the resource is housed in and the specific name of tiie resource (typically a ffle name) on the 
computer. 

Clients and services (both may be implemented on devices as software and/or firmware) may be connected 
over the Internet, a corporate intranet, a dynamic proximity network, within a single computer, or by other network 

5 connection models. The size and complexity of the devices supporting clients and services m^ range, for example, 
fi-om a suiq)le light switch to a complex, highly available server. Example devices inchide, but are not limited to: 
PDAs; cellular phones; notebook, laptop, and more powerfid PCs; and more powerful computer systems, up to and 
including supercomputers. In some embodiments, the distance, latency, and iiiq)lementation of clients and services, 
may be abstracted, with a common discovery and communication me&odology, creating a "black box" effect Thb 

10 definition approach allows software implementation issues to be dealt witfi by tiie underlying platforai, yielding a 
loosely coupled system that may be scaled to Intemet proportions. 

The distributed coiiq)uting environment may provide an Internet-centric programming model including 
WEB and XML content representation, dynamic device discovery, and secure device communication tiiat is 
accessible from a wide range of network devices. The distributed computing environment may include a network- 

15 programming model abstracted above the CPU level. The programmmg model may mclude the foUowmg properties: 

• URI addresses ' 

• Strongly tjTped data called content (addressed with URIs) 

• Substantially unlimited amount of persistent content storage (e.g. stores), (containing XML and non-XML 
content, such as that identified by MIME types) 

20 • SubstantiaDy unlimited amount oftransient content memory caUed spaces (containing X^^ 

• Descriptive XML metadata (data about data) content advertisements that may be stored in a space to notify 
interested clients. 

• A substantialfyurilimited number of instructions (embodied as messages) 

• Secure message endpoints (gates) addressed by URIs 

25 • Data flow support (event messages) to coordinate work flow between distributed software programs 

Services and clients may run as programs witiiin the distributed computing environment Services 
advertise their capabilities to cHents wishing to use the service. Clients may or may not reside wilhin the same 
network device, and that device*s code execution environment may or may not support the Java platform. 

Using URIs to address content and message endpoints ^ves tiie distributed computing environmoit a 
30 powerfid addressing scheme. The address may specify the location of the content or endpoint, and may specify the 
route (or transport protocol) to be used. Items addressed using URIs also may have an associated security 
credential. The security credential may be used to control what clients are ^owed access to the item, as well as 
v^ch operations authori2«d clients are allowed to perform on liiat iteni. 

The high degree of access provided by the distributed computing environment may be controlled by 
35 appropriate authentication and security systems and metiiods. Audienticadon and security in the distributed 
computing environment may include, but are not limited to: verifying tiie typing correctness of XML content in a 
message; securefy identifying the sender to tiie receiver, a mechanism to check the mtegrity of messages sent firom a 
client to a service and vice versa; and a mechanism of describing a service's set of accepted messages to a client and 
enforcing tiie message requirements on messages received at tiie service. The above listed security and 
40 authorization features may be leveraged in a single, atomic unit of code and data. The atomic unit of code and data 
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be dynamically created. In one embodiment, once created, the atomic unit of code and data may represent a 
message endpoint (gate), and may not be altered as to the security and authorization policies implemented during . 
creation. 

A gate may represent the authority to use some or all of a service's capabilities. Each c^ability may be 
5 . expressed in terms of a message that may be sent to a service. Gates may also be used for feilure case detection 
when a client leases resources. 

Authentication and security may also include a mechanism for verifying that a client attempting to use a 
service is authorized to use the service; that the space from which the client receives the service advertisement from 
is audiorized to provide the service advertisement; and/or that the service advertisement itself is authorized. 
10 Message passing may be implemented in a messaging layer as the means of communicating requests from 

clients to ser«ces and ofthe services respondmg with results to the clients. ITie messaging layer of the distributed 
computmg environment may substantially guarantee that valid XML messages are sent, and m^ provide, 
mechanisms enabling a language-independent security model In the messaging layer, a sending message en<^int 
may be linked to a receiving message ehdpomt The two associated message endpomts may provide a secure, 
15 atomic, bi-directional message channel suitable for request-response message passing between a client and a service. 
In embodiments of a cKstnT>uted computmg envin)nment, an advertiseme^ 
aservice. Anadvertisementmay be an XML document that includes the XML schema and XJRI of tiies^ Tbs 
service may also include a service ID token or credential in the advertisement, and may specify in the advertisement 
an authentication service to be used by both the client and the service. A client may then locate the service 
20 advertisement on the space, and use the advertisement to instantiate a message gate on the client The client m^ use 
the authentication service specified m the advertisement to obtain an authentication credential for sentog in 
messages to the client In one embodiment, the client may pass tiie service ID token or credential fit>m the service 
advertisement to the authentication service, and the authentication service may then use the service token or 
credential to generate the authentication credential for the client In one embodiment, the client may include a gate 
25 fectory that receives the necessary information to create the message gate, and the gate fectory may construct the 
message gate and communicate with the authentication service to obtam the auftenticatipn credential for the client 
A corresponding service message gate may be instantiated at the service. 

The cUent, at some point, sends a first message to the service. In one embodiment, the client message gale 
may embed the client's authentication credential constructed by the authentication service in the message. When the 
30 service receives the message, it may use the same authentication service to verify the authentication credential 
received m the message. By sharing the same autiientication service, any of a variety of authentication protocols 
may be employed, widi the details of generating the authentication credentials separated from Ihe client and the 
service. Thus, a client may use different authentication credential protocols witii different services. 

In one embodiment, the authentication service may determine die capabihties of the clidit (e.g. what the 
35 client is allowed to do on the service) upon first receiving ttie client authentication credential from the service. The 
capabilities of tiie client may be bound to the client's identify. Then, tiie client's message gate may embed the 
authentication credential in every message sent fit>m the client to tiie service. The messages may be received by the 
service message gate and then checked by the authentication service to ensure that the message is from the client and 
that the message request is within tiie capabilities of the cHent In anotiier embodhnent, tiie service message gate 
40 may handle capabifify determination and message checking for capabilities without usmg the authentication servicp. 
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The client and service message gates may work together to provide a secure and reliable, message channeL 
The gates mzy serve as secure message endpoints ihat allow iho client to run the service by seaiding and receivmg . 
secured, authorized XML messages to and from the service. 

Operations in the distributed computing environment may be embodied as XML messages sent between 
5 clients and services. The protocol used to coimect clients with services, and to address content in spaces and stores, . 
may be defined by the messages that can be sent between the clients and services. The use of messages to define a 
protocol may enable many dijOferent kinds of devices to participate in the protocol. Each device may be firee to 
• iniplement the protocol in a maimer best suited to its abilities and role. 

A service*s capabilities may be e^qpressed in terms of the messages the service accepts. A service's niessage 
10 set may be deiSned using an XML schema. An XML message schema may define each message format iising X^ 
typed tags. The tag iisage rules may also be defined in tiie schema. The message schema may be a component of an 
XML advertisement along witti the service's message endpoint (gate) used to receive messages. Extensions (more 
capabiHties) may be added to services by adding messages to the XML message schema. 

In the distributed computing ehviromnent, authorized clients may be able to use all of a service's 
15 capabilities, or may be limited to using a subset of the service's capabilities. In one embodiment, once a set of 
capabilities h;as been given to a client, the client may not change that set without proper authorization. This model 
of capability definition may allow for services levels that run from a base set of c^iabilities to an extended set 

Service instantiation may be peifonned to aUow a client to run a service. To instantiate a service, a client 
may first select one of the service advertisements published in a space. The client may use the various feicilities 
20 provided by the space to look up advertisements in the space. Then the client may request the space to instantiate 
the service. Service instantiation may include, but is not limited to, the following steps: 

1. Client requests space service to instantiate a service. 

2. Space service verifies client is allowed to instantiate the service. 

3. Space service obtains a lease on the service advertisemrat for the client with the lease request 
25 time specified by the client Alternatively, the service advertisement may be provided to the 

client without using the leasing mechanism. 

4. Space service sends a message to the chent that includes the lease aDocated in steps 3, and the 

service advertisement of the service. 

5. CUent runs the autheritication service spedfied in the sersdce advertisement, and ob 

30 authentication credentiaL 

6. Client constructs a clieiit message gate for communicating with the service. 

In order to provide trust between clients and services in the distributed computing enviromnent, a series of 
dynamically generated numbers (keys, or tokens) may be used as security or authentication credentials for clients. 
One or more credentials may be used to verify the right of a client to use a service and to verify niessages between 
35 the client and the service. Each client and service may have a unique credential. 

The type of authentication credential needed to use a service may be returned to the client conducting a 
service search. In one embodiment, an authentication credential is an opaque object tiiat must be presented each 
time a client uses a service. In one embodiment, the authentication credential may be presented by a niessage gate 
oh behalf of a client in every message sent to a service. No matter what kind of authentication credential is required 
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by a service, by using an authentication service external to tiie client and the service, the client and the service may 
not need to be aware of the authentication credential structure or of the autibenticatipn process. 

An authentication credential may also include a transport-specific ticket in addition to the service ticket 
When running a service, depending upon the networking transport specified in the service advertisement, the 
transport may provide a secure connection. In some cases, if the data link layer is already secure, it may not be 
necessary to use a secure transport over the already secure data link laya:. 

The concept of an authentication credential is abstract enougji to allow various levels , of security based 
upon credential implementation. Levels of security may include, but are not limited to: 

1 . None (no message security - credential is empty or no credential) 

Messages with empty credentials or no credentials may be sufBcient vrfien security is enforced 
by the physical connectivity properties of the transport For instance, a smart light switch 
connected to just one ligjit switch controller is secure because the switches are wired in a 
secure manner. 

2. Signed messages (digital signatures) 

Signed messages may include a digital signature that enables the service (receiving the 
message) to verify die origin (client) of the message. 

3. Encrypted messages (transport may handle this) . 

Encrypted messages add another level of security by scrambling the message contents so that 
another credential is required to unscramble It 

4. Capability messages (service fimcticnality and user aware 

This level of security may provide for security capabilities on a user-by-user basis (e.g. vi/bBt 
the user is allowed to do), and may allow for fine-grained access control to services and 
individual service functions. 
Multiple levels of security zones m^ be used, due to the heavyweight implementation necessary to aiforce 
the higher levels of security (c^abihties & encryption). If tiie message transport supports (or helps support) tiiese 
security leveb, the support may be leveraged to provide security level bridge services that bridge one level of 
security to another. 

As mentioned above, services without any security model may accept empty authentication credentials. For 
services that do not restrict access, a gate may be built without an airthentication credential or with an "empty" 
authentication credential The gates for such services may not send an authentication credential with each message, 
or may send an empty credentiaL The authentication service is one example of a service that may not restrict access. 
Other services may require a user and password pah:. 

Authenticating Service Access using Credentials 

in some embodiments, a mechanism for verifying that a client attempting to run a service is an authorized 
client, for verifying tiiat the service advertisement received by the cUent is an authorized service advertisement, 
and/or for verifying that the space from which the client received the service advertisement is authorized mzy be 
based upon a public key/private key asymmetric cryptographic mechanisrrL- In this mechanism, an authorized 
" sending entity may embed a public key in a message and encrypt the message including the public key with its 
private key.. An entity receiving the encrypted message may decrypt tfae.message usmg the public key and find the 
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same pubHc key embedded in the decrypted message, and thus verify fcat the message is from the authorized entity> 
since only that entity has the private k^ necessary to encrypt the me^^^ Thus, an entity may issue a credential 
that is substantiaUy unfoi^eable, and that other entities may decrypt (with the appropriate public key) to verify 

messages sent by the entity. 

Various key generation algorithms may be used in the distributed computing envbronment The 
composition of keys may be hidden from both clients and services; thus, the client and service may not care what 

key generation algorithm is used. 

A Kerberos ticket is one example of a security credential that may be used in the distributed computing 
environment Kerberos is a secure method for authenticating a request for a service in a computer network. 
KerijCTOs lets a user request an encrypted "ticket" from an authentication process that can then be used to request a 
particular service, lire user's password does not have to pass through tiie network. 

Mechanisms inay be provided by the distributed computing environme^ 
messages sent between clients and services are not compromised. In one embodiment a sender may embed a token 
containing mformation that may be used by the receiver to verify that the message has not been altered. There are 
15 several methods for generating the information to embed in the message. In one embodhnent, a hash of tire message 
may be conq)uted and sent with the message. Hashing nmy inch^^ 

vsaaify shorter fixed-length value or key diat represents the original string. Upon receiving Ae message, the 
receiver may recompute the hash and check it against the sent hash. If the message has been altered, it is highly 
unlikely that the same hash win be generated. The sender may encrypt the hash and send the corresponding pubHc 
20 key in the encrypted message to substantiaUy ensure that the hash is not comprom 

In other embodiments, an error detection scheme such as cyclic redundancy checking may be used. Cyclic 
redundancy checking is a method of checking for errors in data that is tn^ Inan 
embodiment using cyclic redundancy checking, the send^ ^pUes an n-bit polynomial to the message and appends 
the resulting cyclic redundancy code (CRC) to the message. The receiver q>pUes the same polynomial (v*ich may 
25 also be passed in the rnessage) to the message and compares its result wi& Ifthey 
agree, the message has been received successfoUy. Knot, the sender m^ be noffi^ 

Gate factories may also pl^ a role m security, smce a gate fectory may be •trusted" code. Using a trusted 
gate fectory to generate gates may help to ensure that gates are trusted code, and that the code is correct with respect 
to the service advertisement Clients may be required to present a client ID token or credential to die gate fectory as 
a means of authentication. Services may present a service ID token or credential to cheats (e.g. through an 
advertisement) wiien a client wishes to create a gate. As discussed herein, a client and service token pair may be 
used to create a tiiird credential that may be used to allow the cUent to send messages to fee service. This third 
credentialmay be referred to as an aufeentication credential An authentication credential may be created by an 
authentication service during the aufeentication process. In one embodhnent, the service may use any aufeentication 
35 policy at its disposal! In one embodhnent, fee aufeentication service admmisters fee aufeentication poHcy on behalf 
of fee service, and feus fee service does not have to be aware of fee particular aufeenticatiori poHcy bemg used. 

The client may construct its gate usmg an aufeentication credential feat fee client receives by nmnmg an 
aufeentication service specified m fee service advertisement This may allow fee coristructed gate to send fee 
' authentication credential wife each message to fee service. When fee service receives fee &st aufeentication 
40 credential m a first message from fee cUent, fee service m^ use fee aufeentication service specified in fee service 
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advertisement to authenticate tiie client, and tbus may establish a binding of the authentication credential to the 
identity of the client 

As previously discussed, some results produced by a service niiay be advertised in ia space and ultimately 
accessed using a results gate. The results gate may or may not contain the same security credential as the input gate 
used to generate tiie results. Because input to a service may be asynchronous firom its output (the results), the results 
may have a different set of access rights associated with it For example, a payroU service m^ allow a different set 
of clients to initiate payroll than to read the payroll service's results (paychecks). Thus, a client may have to go 
through a separate authentication process to obtain access rights to the results, vMch may include receiving an 
authentication credential for the results from an authentication service specified in an advertisement for the results. 

Message gates may ofQoad most security checks IBpom services. Services may focus on providing capability 
and authenticating clients. A principle of least privilege m^ be supported by giving clients access to only tiiose 
capabilities tiiat are requested (or assigned). 

Security checks may occur when a gate is created and/or when a gate is used fwhea messages are sent 
and/or received). When a client requests access to an advertised item (service), the process of gate creation may 
be^. During this process, the client gate factory may work with the service to mutually authenticate each other. 
The checks perfoimed at gate creation time may be extensive, and may minimize the niumber of checks pofonned 
during gate usage. After the service has authenticated the cUent, the service inay detennine sped^ 
the client (e.g. what the client is allowed to do on the service), and associate tiie capabilities with the client's 
authentication credential. These specific capabilities may specify what operations the client is allowed to perform 
on the service. Since tiie gates may ensure tiiat every naessage contains the au&entication credential, the service can 
then check each request when it is received against the capabilities of the authenticated client 

Gate creation checks may ensure that a client has permission to use some or all of the service capabilities 
designated by the XML message schema. In one embodiment, tiiese checks may be nnplemented using access 
control lists (ACLs) in conjunction with an authentication service such as Kerberos. A challenge-response sequence 
(such as a password) may also be used to authenticate a cUent In some embodiments, a hardware-based physical 
identification metiiod may be used to authenticate the cHent For example, the user m^ supply a physical 
identification such as a smart card for identification and authorization. Other mechanisms for authentication way be 
used m other embodiments. 

In one embodiment, v^hatever means is used to authenticate the client, the authentication may be invisible 
to both the cli^t and service, tiie gate fectory may be aware of yMch authentication service to use, and the 
authentication service handles the authentication mechanism and policies. Gate factories may be product and 
ravironment dependent, or m^ even be controlled by a configuration management system. In one embodiment, the 
degree and metiiod of client isolation may be platform dq)endent, but is known to the gate fectoiy. In some 
embodiments, a hardware-based physical identification method may be used to authenticate the client For example, 
tiie user may supply a jphysical identification such as a smart card for identification and authorizatioo. Other 
mechanisms for authentication may be used in other embodiments. 

Message gates in the distributed computing environment are typically associated with a singje client The 
gate fectory may detennine the means of association. The checks performed at message send tnne may ensure tiiat 
the proper client is using the gate. In one embodiment, gates may be passed in messages, and may be cloned if a new 
client wishes to use the gate. The cloning process may perform a new set of creation checks. 
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Once a client of a space (the client may be another service) finds the advertisement of a space service, tiie 
client ofthe space may run Ae space service, as it would any otiber service. Rimninjg a space service may involve 
usmg an authentication mechanism. Running a space service may include, but is not limited to: 

1. The client of the space may first rtm an authentication service that may be specified in the 
5 service advertisement of the space service to obtain an authentication credential 

2. ITie client of the space may use the audientication credential, the XML schema of the space 
(from space's service advertisement), and the URI of the space (from space's service 
advertisement) to construct a gate for the space. In one embodiment, the client may pass the 
information to a gate factory to construct the gate. 

10 3. The client of the space may run the space service by using the gate to send messages to the 

service. 

4. When the space service receives Ihe first message from the client, with the authentication 
credential embedded, the space service may use tiie same authentication service used by the 
client to obtain tiie authentication credentiai to authenticate the client, thus establishing the 

15 client's identity. 

5. The space service may then determine the cliaifs capabilities (e.g. vfbat the client is 
aUowed to do on the space seivice) and bind the capabiUties to the a^ 

As discussed in tiie Spaces section, a space's fecilities may include an interfece for spawning an empty 
space with substantially the same functionality (same XML schema) as the space from which it is spawned. The 
20 spawning fecility may be useful, among other things, for dynamically generating spaces for results. When a 
requestor has spawned a space, only tiie requestor may be allowed to access the spawned space. For example, tiie 
spawned space may be for storing results from a sendee that tiie client needs to keep secured. This security m^ be 
ensured by: 

• Creating an initial root authentication credential, and initializing the audientication service of the spawned 
25 space, so tiiat the authentication service only autiienticates the root authentication credential, and so that it 

returiis no other audientication credentials (no other cUents of the spawned space aDovred ^ 

• Initializing the security policiw of the spawned space so tiiat tiie root identity associated with the root 
authentication credential has access to ail fricilities of the space, inchiding tiie security admimstration 
^cUities. 

30 • Returning the root authentication credential and tiie service advertisement of the spawned space to the 

requestor of the spawned space. 

The requestor may build a gate to access the q)awned space, since it is returned the authentication 
oedential and the service advertisement of tiie spawned space. In one embodnnent, only tiie requestor and clients or 
services tiiat the requestor passes the audientication credential and tiie spawned space's service advertisement may 
35 access the spawned space. Suchlinutingof access to the spawned space may be useful when a chent and service are 
using tiiat spawned space to store results, for example, if the client and service desire to keep the results private. 

After running a service, the client may change the authentication policies of the spawned space usmg a 
security administration space fecility, and other clients or services may then access tfie spawned space. In addition, 
tiie spawned space's service advertisement may be made available t other clients of tiie spawned space (tiie other 
40 clients may be services) using the discovery protocol or other means. 
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The. message transport layer in a distributed computing environment may include mechanisms for 
protecting the security and iategrity of communications among clients and services during transport. This security 
may be referred to as "wire security" or "transport security" to distinguish it from the authentication security 
implemented by the messaging system including gates. Encryption of messages may be provided at the message 
transport layer of the distributed computing environment Services that request an encrypted transport may do so by 
tagging the XML advertisement Hie gate factory may then create a gate (or gates) that uses a secure message 
transport such as ttiose provided by Bluetooth and HTTPS. 

HTTPS (Secure Hypertext Transfer Protocol) is a Web protocol that encrypts and decrypts iiser page 
requests as well as the pages that are returned by the Web server. HTTPS m^ use a multi-bit key size (may vary 
from 40 to 128- bit or more) for a stream encryption algorithm (e.g. RC4), to provide an adequate degree of 
encryption for cornmercial exchange. HTTPS may be used as a transport in the distributed computing environment 
Bluetooth is an emerging peer-to-peer wireless communications standard. The Bluetooth key gieneration 
edgori&ms may be used m the distributed computing environment Bluetooth may support encryption keys. 
Encryption keys are transport dependent, while client, service, and combination keys may be transport independent 

Figure 26a - An authentication service providing an authentication credential to a client 

Figure 26a is a flow diagram illustrating an authentication service providing an authentication credential to 
a client according to one embodiment A client in the distributed computing enviroimient niay desire a service to 
perform one or more functions on biehalf of the client In one embodiment, an authentication service may be 
provided for use by the client and the service when setting \xp a secure messaging chaimel. An aiithentication 
service may perform functions for the client and/or service including authenticating the client and/or service and 
negotiating the desired level of security and the set of messages that may be passed between the client and service. 
The authentication service may be a process that is execirting within the distributed computing erivirormiait The 
authentication service may be executing on the same device as the service and/or the client, or alternatively the 
authentication service may be executing on a separate device such as an authentication server. In one embodimerit, 
the authentication service may be an Internet-based service. The authentication service may have its own address, 
for example, a Universal Resoiirce Identifier (URI), through which the client and/or service may communicate witii 
the authentication service. In one embodiment, the address of the authentication service may be provided to the 
client in the service advertisement for the service. The client and service sharing an authentication service may help 
insure that a secure messaging charmel may be established between the client and the service, as any of several 
security and authentication protocols may be used in the messaging channel. 

In one embodiment, a client may present a client identification token or credential to an authentication 
service. The client token or credential may be sufficiently unforgeable to be used as proof of the client's identity. 
The authentication service may then check the client identification token or credential, and issue to the client an 
authentication credential, that only the authentication service can create. The authentication credential that is 
returned to the client is then sent in every message by the client to the service. In one embodiment, the client 
message gate is created by a gate frictory, which includes the autiientication credential in the message gate, and thus 
tiie message gate includes the authentication credential in every message tiiat it sends to. the service on behalf of the 
client When receiving a inessagej the service may then check ttie authentication credential Since only the 
autiientication service can create die authentication credential, the service knows that the client did not forge the 
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audiendcadon credential. In one embodiment, the service may pass the authentication credential to the same 
audientication service used by the client to ensure the authentication credential is valid, to verify that the client is an 
authorized client, and to find out the identity f the client 

All services, including space services and authentication services, may authenticate their clients. Once a 
service audienticates a client, the client may access the service. For example, in the case of a space service, a client 
may then obtain XML advertisements from the space. 

In one embodiment, a service may have a prearranged credential that all clients of the service are to use. In 
this embodiment, the authentication may provide the prearranged , credential to a requesting client. Any client . 
presenting the prearranged credential to the service may be £q>pn)ved by the service. 

In step 1000, the client may request an authentication credential from the authentication service, in one 
embodiment, the client may search for and locate a service advertisement for tiie desired service. In one 
embodiment, the service advertisement may include an advertisement for the authentication service to be used to 
obtain an authentication credential to be used in accessing the sendee. In one embodiment, Ihe service 
advertisement may include an address such as a URI for the authentication service. In one embodiment, the client 
may send information to the authentication service requesting the authentication credentiaL In one embodiment, the 
client may send information to a gate creation process, for example, a gate fectory, and the gate creation process 
may access the authentication service to obtain fbe authentication credratial. 

In step 1002, the authentication service may generate an authentication credential for the client The 
authentication credential may be a data element or data structure that may be embedded in messages in a messaging 
system and that may allow receivers of the messages to auth^iticate the sender of the message, to verify the message 
is from an authorized sender, and to verify that the message is a message the sender is allowed to send to the 
receiver. In one embodiment of a distributed computing environment, an authentication credential may be unique to 
the messaging channel set up between a particular client and a particular service. Step 1002 is further illustrated and 
described in Figure 26b. In step 1004 of Figiffe 26a, Ihe authentication service may return the authentication 
credential to the client In one embodiment, the au&entication credential may be returned directiy to the client In 
one embodiment, die authentication credential may be returned to a gate creation process, for example, a gate 
fectory, \^Wch may then use the authentication credential in generating a gate. 
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Figure 26b - An authentication service generating an autfaenticgtion credential 

Figure 26b is a flow diagram expanding on step 1002 of Figure 26a and illustrating an auftentication 
service generating an authentication credential according to one embodiment In step 1002a, in one embodiment, 
the authentication service may obtain a client token and a service token. In another embodiment, the authentication 
service may obtain only a client tokea In one embodiment, the cUent token may be a unique identifier for the client 
in the distnljuted computing environment to one embodnnent, fte service token 

service in the distributed computing environment For example, the pubKc keys from a public/privatb key 
. encryption mechanism may be lised as unique identifiers for fte cUent and the service. In one mbodiment, the: 
client may receive the service token in the service advertisement, and the client may provide the cUent token and flie 
s«vice token to the authentication service. In another embodiment, the client may provide the client token and tiie 
service advertisement URI to ttie authentication service, and the auflientication service may retrieve the service 
token fi^om flie service advertisement 

In step 1002b, tte authentication service may verify the client and/or the service. In one embodiment, the 
. authentication service may use the client token and the sendee token obtamed in step 1002a to verify the cUent 
5 and/or service. In another embodiment, only a client token was obtained in step 1002a, and dim only the cUent 
token is used to verify die cUent in step 1002b. In one embodnnent, the client may have previously registered its 
client token v«th the auflientication service, and die authentication service may con5)are flie received client token to 
the registered cUent token to verify the cfient as a vaUd client In one embodnnent, the cUent may access the 
authentication service iising a challenge/response mechanism such as a logon account with password and thus may 
10 be verified as a valid client In one embodiment, the service may have previously registered with flie authentication 
service, and may have provided its service token to the authentication service. Hie auflientication service m^ then 
vertf / that the cUent is attempting to access a valid SMvice by comparing the received service token to tiie previously 
registered service token. Oflier types of cKent and service auflientication may also be used. For example, tiie client 
may provide a digital signature or di^ certificate tiiat tiie authentication service m^ use to auflienticate tiie cliait 
25 and/or to authenticate the service the client is faying to access. 

hi step 10P2c, the authentication service may generate an authentication credential, to one embodiment, 
die authentication credential include an auflientication token that onty die authentication services to 
one embodnnent, file auflientication service may use flie cUent token and die service token in generating flie 
auflientication credential to another embodiment, die auflientication service may use. just tiie cUent token to 
30 generate flie auflientication credential, to yet anoflier embodnnent, flie auflientication service may not use an 
obtained token m flie generation of flie auflientication credential, but may instead use an auflientication credential 
generation algoriflun to generate a substantiaUy unforgeable auflientication credentiaL to one embodnnent, flie 
auflientication service may combme flie service token and client token to create a unique auflientication credentiaL 
For example, flie service token and cUent token may be 64-bit values, and tiie two tokens may be combmed to 
35 . generate a 128-bit auflientication credentiaL Otiier embodiments may use oflier methods to generate an 
auflientication credential. 
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Bridging Devices t Ihe Distributed Netw oric EnvironmeDt 

TTiere nay be, devices/ external to tbe distributed compu^^ . 
message passing model implemented by the distributed computing environment THese devices may provide 
services that may be use&l to cUents in the distributed conq>utjng environment Hie distributed computiiig. 
environment may include a mechanism to bridge such external devices to the distributed computing environment so 
that clients in the distributed computing envfa-omnent may access the services ofifered on such devices. The 
distributed computing enviromnent may also leverage existing device discovery protocols for discovering such 
external devices for use in the distributed computing environment 

Many technologies define discovery protocols for publishing and monitoring a netwoiKs device 
composition. Hiese technologies include, but are not limited to: Jmi. SLP, Bluetooth, and UPnP. Furthennoie. 
many I/O buses such as LonWoiks. USB and 1394 also support dynamic discovery protocols. The distributed 
computing enviromnent may leverage device discovery technologies by xvrappmg their implementations in an APL 
Leveraging other device discovery protocols and providing a method to bridge to other discovery protocols may 
allow the distributed computmg enviromnent to discover devices or services on a wide variety of network and I/O 
buses. Device discovery in the distributed computing environment may thus be appUcable to a wide range of 
devices including smaU devices such as PDAs, even if Ihey do not participate directly in the distributed computing 
environment Discovery protocols m^ be defined at flie message leveL 

A bridging nKxaianism may be provided for ^vrappmr one or more specific device dk^^ 
such as Bluetootfa's, inamessagmg API for the distributed computing enviromnent Wrapping may inchide fiaming 
the device discovery protocol with code and/or data (the API) so that the protocol can be run by cHents and/or 
services in the distributed computing enviromnent that would not otherwise be able to run it When nm. the 
bridging mechanism may allow for a discovery agent (hat discovers devices by a specific device discovery protocol 
to publish services for those devices in a space in tiie distributed computing enviromnent The services . present an 
XML message schema interifece to clients in the distributed network enviromnent and are capable of operating the 
various devices discovered by the specific device discovery protocol Thus, service advertisements may be 
published for the services that operate the various devices discovered .by the miderlying wrapped device discovery 
protocols, lie advertised services thus bridge devices (or services) external to the distributed network cnv^ 

to clients on Ihe distributed network environment 

Figure 27 illustrates one embodiment of a distributed computinig environment with a space 1200. One or 
more discoveo^ agents 1204 may participate in an ertemal discovery protocol and bridge to the distributed 
computing enviromrrent through bridging mechanism 1202. When the wrapped device discovery protocols are run. 
discovery agents 1204 through bridging mechanism 1202 may publish service advertisements 1206a-1206c in spiice 
1200, wherein each one of advertisements 1206a-1206c corresponds to a device or service discovered by one of 
discovery protocob 1204 outside the distributed computing enviromnent Clients may then access fte external 
35 . devices using flie service advertisements 1206a-i206c in space 1200 to instantiate services on one of die agorts 
1204 fliat operates the corresponding external device or service. 

Thus, clients of flie distributed computing environment may use discovery agents wrappmg device 
discovery protocols to find devices.. A service acting as a bridge to these devices may be published in a space and 
' advertised, so cUents of the distributed computing environment may access the services provided by tire external 
4b devices. The advertised service is a service within the distributed computing enviromnent that is able to invoke a 
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device outside the distributed computing environment via another protocol or environment, thus brid^ the outside 
device/service to the distributed computkg eavironment A cUent within the distributed computing environment 
"sees" only the advertised service within the distributed computing environment and may not even be aware of die 
outside device/service, . . 

5 In one embodiment, the distributed computing environment may provide a version of a space discovery 

message protocol, such as the discovery protocol described in the Spaces section, that may be mapped to an 
underlying external device discovery protocol, including the wrapped device discovery protocols described above. 
The mapped discovery protocol may register itself or be revered with a space, e.g. a defeult space, by placing an 
advertisement m that space. For each advertised discovery protocol, a subsequent results space to hold the results of 

10 the discovery protocol may be provided. 

Figure 28 iUustrates an example of the space discovery protocol m^ped to a Blu 

1220 according to one embodiment The Bluetooth discoveiy service 1220 may first leg^stw 1230 with the 
distributed computing environment The Bluetooth discovery service 1220 may be wrapped in a brid^ API, and 
an advertisement 1225 for the discoveiy service 1220 may be added 1232 in space 1224. A client or service may 
15 locate die discovery service advertisement 1225 on space 1224. When die discovery service 1220 is executed 
(utilizmg the API wrapper as a bridge between the discovery protocol 1220 and the distributed computing 
eavironment 1222), a new space 1226 may be created 1234 to store the results of the discoveiy process. Hie 
discovery service 1220 may store the results (again through the API wrapper) to discovery results space 1226 as one 
or more advertisements 1227. Alternatively, results of executing discovery service 1220 may be stored to space 
20 1224 or other pre-existing spaces m the distributed computing environment A shnilar mediod as iUustrated in 
Figure 28 may be used to discover devices and other services using other underlying discoveiy protocols. 

As mentioned above, diere may be devices, external to the distributed network environment, vMcli do not 
support the message passmg model implemented by die distributed network environment Hiese devices may have 
clients diat may want to use services provided in the distributed computing environmoit The distributed conq)uting 
25 environment may provide a mechanism to bridge the external cHents or cHent devices to die distributed computing 
environment so tiiat the cUents on die external devices may access services m die distributed compitfrng 
environment 

Agents may be provided diat serve as cHents in die distributed conqiuting environment to bridge external 
clients to die distributed computing environment, allowing die external cUents to access services published in die 
30 distributed computing environment In one embodiment, an agent may have an XML^nabled back end cq)able of 
communicating widi services in die distributed con^)uting environmart usmg die message passing model, and a 
proprietary protocol (e.g. a protocol si^ported by die external device) on die fixmt endto interfece to die external 
device, and dius to the external client Thus, a cUent extertial to die distri^ 

and access services in die distributed computing environment dirough die bridging agent, and m^ send requests to 
35 the services and receive responses from die services, including results data. For cxanq)le, an external cUent m^ use 

the bridging agent to run space discovery in die distributed computing enviromn^t, look up advertised services, and 

mvoke services in the distributed computing environment 

In one embodiment, die. distributed computing envhronment may provide a bridging mechanism for 

accessmg Jmi services from a distributed computing environment cUent Smce Jini services may require Remote 
40 Method Invocation (RMI), and since clients in die distributed computing environment m^ communicate to services 
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using messages such as XML messages, a protocol bridging mechanism may be provided to enable the access of a 
Jini Service by a distributed computing environment client In one embodiment, a connector mechanism may be 
defined that enables the dynamic advertisement of Jini services m distributed computing environment spaces, and 
that also may enable the accessing of a Jini service proxy j&t>m clients in the distributed computing environment In 

5 one embodiment, there may be Jini services that may not be bridged to the distributed computing environment 

In one embodiment, an agent may be provided as a service in the distributed computing environment that 
bridges the Jini RMI protocol used by Jini services to XML messaging used by distributed computing environment 
clients. When the agent is started, the agent may perform a lookup on the Jini spaces for Tmx services Aathave a set 
of attributes. For every re^stered Jini service, Hie agent may generate an XML advertisement that may correspond 

10 to the service and may re^ster the advertisement m a space m the dishibuted computing environment In one 
embodiment an agent may register for evait notification in the Jini Lookup service, a^^ 
a new Jini service is registered . When mformed of a new Jini service, the agent may per* 

to locate newly advertised Jini services and to update the distributed computing envhonment ^ace with new XML 
advertisements for the new services. In one embodiment, when a Jini service is removed, the agent may recieive an 
15 event notifying of the removal of the Jini service. The agent may then remove the XML advertisement for the 
service from the space. 

1b one embodnnent to invoke a Jini service via an XML advertisement in a distributed computing 
environment space, a client may look up tiie service advertisement in the space and may send valid messages to tiie 
agent to access the service. The agent may invoke the proxy service corresponding to the Jini service by invoking 
20 the corresponding method through an RMI caU to a service proxy. If the proxy is not instantiated, the agent may 
download the proxy code and mstantiate a new instance of the proxy object In one environment, every cHent 
connection may have a diflFerent proxy-instance. The incommg message from tiie client m^ be converted by the 
agent mto a method call for the proj^. The result from the method call m^ be returned to the cHent as an outgoing 
message. 

25 hi one embodim^t only simple Java types may be used as arguments to an RMI method. If complex Java 

types are required, then one or more data advertisements may be passed as ai^guments to the call, v^ere tiie data 
advertisements may indicate the location and access method of data for the complex Java types. In one 
embodiment, the agent may perform initial conversion from XML messages to an RMI method call mvocation 
dynamically. Since, the agent knows the service mterface, it m^ generate the correspondmg set of messages that are 
30 advertised to the client 

Figure 29 illustrates bridging a client 1250 external to the distributed computing environment to a space 
1254 in the distributed computing environment Bridging agent 1252 may serve as the go-between between client 
1250 and space 1254, Bridging agent 1252 may communicate with client 1250 in a communications protocol 
understandable by the cUent 1250. Bridging agent 1252 may map the cHent*s conmnunications protocol into the 
35 XML messaging protocol necessary to communicate with spiace 1254 perform the fecilities provided by space 1254. 
Bridging agent 1252, at client 1250's request, may locate and run services on space 1254. For example, elicit 1250 
may request a list of aU services of a particular type from space 1254. Bridging agent 1252 may locate service 
advertisements 1256a-c and return the results to cUent 1250. Alternatively, the results m^ be posted in a results 
space, and the location of the results may be returned to the cUent 1250. Client 1250 may then choose to execute 
40 service advertisement 1256a, and may send a message (m the client 1250's communications protocol) to bridging 
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ageut 1252. Bridgmg agent 1252 may then send the XML request message(s) necessary to execute the service 
represented by service advertisement 1256a, and.may return the results of the service to client 1250. Methods of 
handling the results of the service other than directly returning the results to the client 1250 may be used as 
described above in the section titled Spaces. Bridgmg agent 1252 thus may act as a service of the external cUent 
1250 (via the external client's protocol) and as a client within the distributed computing environment to bridge a 
service withm the distribirted computing enwonment to die external clioit 

Sometunes, even within the distributed computing , environment, clients and services cannot directly 
communicate with each other, only to a common space. In this case, the space service will automatically create a 
service pnnQr that bridges client to service. The pro^s main job is to route messages between client and service 
through the space. The service proxy may be created dynamically. The creation mechanism may be dependent 
upon space hnplementation. Refer to Figure 30 for an iUustradon of a pro3Qr mechanism. A client 554 and a sendee 
556 may not be able to communicate directly within the distributed computing envkonment, e,g., because diey 
support different transport or network protocols. Howcvct. they both may be able to communicate with a space 552 
diat supports both protocols. The space service may create a proxy 550 to bridge die cUent 554 to the service 556, 
A common form of prrog^ is a browser proxy. A browser proxy (most commonly implemented as a servlet) may 
translate conventional Web page requests into messages. Refer also to the description of space search services (and 
proxies therefoie) in the Spaces section herem. 

The distributed computing environment may provide a mechanism for bridging clients in die distributed 
computing envh-onment to enterprise services. In one embodiment of a distributed computing environment, a 
method for bridging cUents to enterprise services may include a cUent within the distributed conq)uting environment, 
a bridge service withm the distributed computing environment, and an enterprise service within die enterprise 
environment The distributed computing environment bridge service serves as a bridge service between the client 
and die enterprise service. An enterprise may be a corporation, smaU business, non-profit institution, government 
entity, or otiier kind of organization. An enterprise may utilize an enterprise computing environment for conducting 
a portion of its business. Hie enterprise computing environment may include various enterprise services. Clients m 
the distributed computing environment may desue to use services in die enterprise computing environment An 
enterprise service may be based on a number of architectures, such as three tiered client/server architectures. An 
example of an architecture diat may be used to implement an enterprise service is Enterprise JavaBeans. Enterprise 
JavaBeans (EJB) is an architecture for setting up program components, written in die Java programming language, 
that run in die server parts of a enterprise environment usmg a client/server model. In object-oriented programming 
and distributed object technology, a component is a reusable program building block diat may be. combined widi 
odier components in die same or odier computers in a distributed network to form an application. EJB is buih on die 
JavaBeans technology for distributing program components (Beans) to clients in a networic To deploy an EJB Bean 
or component, it must be part of a specific appHcation, which is caUed a container. In Enterprise JavaBeans. diere 
are two ^es of beans: session beans and entity beans. An entity bean is described as one tiiat. unlike a session bean, 
has persistence and can retain its original behavior or state. Using EJB, programs may be deployed across 
substantially all major operating systems. EJB's program components are generally known as servlets (little server 
programs). The application or container diat runs the servlets is sometimes called an application server. 

The bridge service interacts with die client via XML message passing to gadier input parameters necessary 
40 to make requests to die enterprise service outside of the distributed network environment For example, die bridge 
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service may be looked up and instantiated by the client jtist as any other service in die distributed computing 
environment The bridge service then may interact with the enteiprise service to run the enterprise service. This 
interaction may use an interprocess communications architecture that the enterprise service can understand. As an 
example, if an enterprise service is implemented with Enterprise JavaBeans (EJB), a bridge service may 
5 commuiiicate with the enterprise service using EJB. The bridge service may then receive results from the enterprise 
service and may retum the results directly to tiie client (in XML messages) or may place the results in a space in the 
distributed network environment (e.g. a results space). To tiie client, the bridge service qjpears to be the only 
service (the enterprise service is hidden to the client), so tiie client does not have to support the architecture of the 
enterprise service. Multiple distributed network environment clients may use the same bridge service (each usmg a 
10 unique gate pair) to interact with the enterprise service. 

Hie bridge service or other agent may publish an advertisement fcnr the bridge service (and thus for Ihe 
enterprise service) in a space in the distributed computing environment For exa^^)le, a bridge service or other 
bridge agent may use Java Reflection to examine Beans for services in an enterprise system implemented with EJB,. 
and then create service advertisements for bridge services to the Beans and publish those advertisements in spaces in 
15 the distributed computing environment Reflection is a method for Java code to discover information about the 
fields, methods and constructors of classes, and to use reflected fields, methods, and constructors to operate on their 
Tinderlying counterparts on objects, within security restriction^^ The Reflection API accommodates plications that 
need access to ehher the public members of a target object or the members declared by a ^ven class. Once the 
bridge services are advertised, clients may access the bridge services (and thus the corresponding enterprise 
20 services) simflarly to any other advertised services in the distributed networked 
architecture of the enterprise service providing the services. 

Client Displays 

There are several mefeods in which results from a service run by a client may be displayed in a distributed 
25 computing environment Devices that may display results may inchide, but are not limited to: CRTs on computers; 
LCDs on laptops, notebooks displays, etc; printers; speakers; and any other device capable of displaymg results of 
the service in visual, audio, or other perceptible format The methods for displaymg results may inchide, but are not 
limited to: 

• The service may retuni results to a cHent directly or by reference, and the client may h^ 
30 display of the results. 

• The service may retum results to a client directly or by reference, and the client may pas^ the 
results to a display service directly or by reference, and the display service may display the resuhs. 

• Hie service may directly handle the displaying of the results. 

• The service may pass the results to a display service directly or by reference, and tiie display 
35 service may display the results. 

In the last mediod of displaying results, the client may specify tiie display service. For example, there may 
be a display service on or. associated with the device on which the client resides Aat the cUent wishes to use to . 
' display the results of the service. When the client runs fhe service, the client may send a message to the service 
specifying the service advertisement of the client's display service. The service may then build a gate that allows it 
40 to send messages to the clienf s displ^ service. Thus, \^en displaying results, the service invoked by the cUent 
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becomes a client of the client's display service and sends its results (directly or. by reference) for display to that 
display service. More detail on the client-service relationship, gates, and messaging is included in other sections of 

this document . 

Conventional appUcatipn models are typically based on predetermined, la^^ 
5 . data characteristics. Changes to conventional applications may require code modification and recompilation. The 
mechanisms described for advertising services and for specifying XML message schemas for communicating with 
services in the distributed computing environment may be used to provide a mechanism for ^plications (clients, 
services, etc) to describe dynamic display objects. Using the dynamic displ^ objects, application behavior may be . 
altered without havmg to download new code, recompile, or re-link the application. Display schemas may be 
10 provided for displaying Ac same results m different fomiats, for extracting portions of the results for display, and 
for displaying the results on different display devices. 

Figure 31 ilhistrates one embodiment of a client 1300 with associated display 1302 and display service 
1304 according to one embodiment An advertisement 1306 for display service 1304 may be registered on space 
1308. An advertisement 1312 for service 1310 may be registered on space 1314 by service 1310. Alternative^, 
15 service advertisement 1312 and display service advertisanent 1306 may be registered on tiie same space. Client 
1300 may search for and discover (1320) semcc advertisement 1312 on space 1314, and may then set iq) a gate to 
send requests to (and receive results or responses fixmi) service 13 10. In one embodiment, the messages be in 
the fonn of XML messages specified m an XML schema received as part of advertisement 1312. Client 1300 may 
send one or more messages (1322) to service 1310. The one or more messages may include messages for running 
20 service 1310 and for instructing service 1310 to send results to display service 1304 for display, and may specify the 
location of display service advertisement 1306. The advertisement location may be specified as a Uniform Resource 
Identifier (URI). 

The messages fi-om client 1300 to service 1310 may instruct service 1310 to perform one or more 
operations tiiat produce displayable results. S^vice 1310 may retrieve display service advertisement 1306 from 
25 space 1308 based upon the location information received from cUent 1300. The service advertisement may include 
the XML message schema and other information necessary to interfece with <^play service 1304. Service 1310 
may then set tip a gate to send requests to (and receive results from) display service 1304. hi otiier embodiments, 
messages from chent 1300 to service 1310 may include the XML schema and other information needed for service 
13 10 to constnict a gate to display service 1304, or may include a pre-w^ 
30 During or after completing, operations requested by client 1300, service 1310 may send the results of the 

operations to display sovice 1304 in the manner specified by the schema for display service 1304 (e.g. encapsulated 
in XML messages specified in the XML message schema or by reference as parameters for the display service). In 
this regard, service 1310 may be a client of display service 1304. Display service 1304 may tiien format and display 
. the results received firom or indicated by service 1310 oh display 1302 for the client 
35 In some embddunents, service 1310 may post the results of operations to a space such as a results space 

(iiot shown). Service 1310 may then send a message to display service 1304 mcludmg a reference to die stored 
results of the operations. In one embodiment, tiie reference may be in the formi of a URL The display service 1304 
may tiien retrieve the results from die space and display die results on display 1302. 

Conventional application models are typically based on predetermined, largely static user interfece and/or 
40 data charactwistics. Changes to conventional applications may require code modification and recompflation. the 



77 



wo 01/86394 



PCT/DSOl/15134 



mechanisms described for advertising services and for specifying XML message schemas for communicating with 
services in the distributed computing environment may be used to provide a mechanism for applications (clients, 
services, etc) to describe dynamic display objects. Using the dynamic display objects, application behavior may be 
altered without having to download new code, recompile, or re-link the apphra^ 

The dynamic display objects may be described in XML schemas. Ihese schemas may be advertised in 
spaces. These schemas may be refened to as display schemas or presentation schemas. An application (or other 
services acting on behalf of the application) may then access the schemas firom the service advertisements to display 
data based upon formatting, data type, and odier information stored in the schemas- 

The following is an example of a schema containing dynamic displ^ objects: 

<element namcF="delivay" 1ype?="Space3hipto" minOccurs="0" 

<type name="TextField"> 

<element nam^" Address" typ€f=="string"/> 

<element name="Ci^ type="string"> 

<element name="State" type="string"A> 



</typeP> 

The above schema may be changed to the following without requiring an application recompile: 

<element name="delivery" type="Space:shipto" minpccurs="0" f> 
<type name="TextField'*> 
25 <elementname="Name"type="string"/> 
<element name=" Address" type="string"> 
<element name="City" type="strfng**/> 
<elementnam^"State** type="string"A> 

30 ... 
</type> 

Figures 32A and 32B illustrate examples of using schemas of dynamic display objects according to one 
35 embodiment In Figure 32A, application. 1320 (may be a client, a service, or other application), has been 
implemented with presentation schema advertisement 1324 stored in space 1326, A presentation schema 
advertisement may include elements describing the data types, formatting specifications, fonts, locations, colors, and 
any other information used for displaying data for the qyplicatibn on display 1322. There may be multiple 
presentation schema advertisements for application 1320. For example, &ere may be one schema for each di^lay 
40 page in a series ofdisplay pages (for bcample. Web pages on a Web site). 
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In one embodiment. appUcation 1320 may invoke a discovery and/or looknp service to locate presentation 
schema advertisements. Hie discovery and/or lookup service may return an XML document listing one or more 
advertisements, and UMs to each of the schemas describing a particolar display format, etc. Application 1320 may 
then select a presentation schema or schemas from the XML document AppUcation 1320 may then parse the 
5 schema, breaking out the elements of .the.schema into user interfece components. The components then may be used 
to locate, format, and display results data on the appropriate display. The result data may be from running a service 
or from a results space, for example. Thus, as .opposed to having.a static or predetermined display, the application 
. 1320 is configured to display resiihs accordmg to a presentation schema that may be dynamically changed without 
requiring a rebuild of fte application. 
10 Presentation schemas may be provided for displaying the same results in different formats, for. extractmg 

portions of the r«ults for display, and for displaying &e resulte on different <fi^ 

In one embodiment, one or more Fesentafion schema advertisements m^ be stored m one OT more 

in a distributed computing environment. As copies of an appUcation are invoked on ode or more devices, each copy 
of the application may run a search for services to discover advertisements for the presentation sc^ 

15 appUcations. Ihus, a central, persistent store of the dispbyiriformation may be kept for multiple 

appUcation or for other appUcations. The display mformation may be modified in tire central location vnthout 
requiring tiie recompilation and/or reinstallation of tiieappUcatioiB. 

In Figure 32B, cUent 1328 may locate a semce advertisement for service 1330 on a space. When invokmg 
service 1330, cUent 1328 may pass a location of presentation schema advertisement 1324 on space 1326 to service 

20 1330. When service 1330 is ready to provide r^ts to cUent 1328, it may display the results on display 1322 
(which may be coupled to flie device on which cUent 1328 is rmmmg) usmg flie display information from the 
presentation schema provided by presentation schema advertisement 1324. To change the way tiie results are 
displayed, flie XML messages in tiie presentation schema advertisement 1324 may be modified, or a different, 
presentation schema may be selected, without requiring changes at tiie cUent 1328 or service 1330. Service 1330 

25 may be a display service. 

A cUent. appUcation or service may provide a plurality of display schemas for displaying resute 

operations provided by one or more services. Alternatively, a display schema may include mfomiation for 
displaying a variety of results for one or mor« cUents. Thus, cUent 1328 may use one display schema or aphraUty of 
display schemas. Two or more display schemas may be provided for formatting and displaying the 
30 different formats, or on different displays. For example, one dispby schema for a set of 

displaying results on a display screen, and anoflier for printing tire results. Also, copies of flie same appUcation. 
cUent or service may run on devices witii different display capabiUties, so two or more displ^ schemas may be 
provided for supporting tiie display requirements pf the different devices. 

35 . String Management 

Strmg handling mconventioral systems is graenilly not very effident 

and may be wasteM of memory space, e.g. as flie string is copied and/or moved iri memory. This inefficiency in 

strir>g handUng may be particularly problematic in smaU memory footprint systems such as embedded systems. The 

amount of memory, particularly stack space and space for dynamic allocation, may be Umited in small footprint 
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systems. Thus, a more efficient method of 

such as embedded systems is desirable. 

Figure 33 A iliustrates a typical string representation in the e prograinming 

represented by a character pointer 1450 (stringl) containing amemonr location^(^^^ 

5 string 1452. Other charactersfoUow the first character in the strm^ 

addressablebytelocationsinmemory. CharactersmCstringsaietypicaDy84,it Ttec 

beanyASCncharacter. ACstringmustbeterminatedbyaNUlXcharacter.NU^ . 
the 256 possiTjle 8.bit values, but is typically the binary value ObOOOOOOOO. Tie 

string charactera plus the terminating characto-). 
10 An example of a string operation m C is the strlenO ftnction, typically provided with standard C h1>raiy 

implemcntaticms. ThestrienOftoctiontakesastrii«point« 

not including the tenninating character. For example, passing fte character pointer 1450 to 4e strlenQ &nction 
would return ae length 12. Tie strlenQ Action may be implemented by 'Valkinr the stii^ 
character is located, coimting each character. 
15 String copying in C is typically handled by a strcpyQ or a stmcpyQ C Uteaiy fimctions. viiidi are 

implemMited as: 

char *strcpy(char *dest, const char *src); 
char *stmcpy(char *dest, const diar ♦src, sizej n); 
The strcpyO fiinction copies the string pointed to by the charact^ 
20 thestringpointedtobycharacterpointerdest.Thestringsmaynoto 

large enougJi to receive the copy. 

TtestrncpyQfimctionissimilar.exceptthatnotmorethannbytesofsrcarecopied. Hms, if 1here is no 

tenBinatingcharacteramongthefi.^tnbytesofsrc.theresultvdUnotbetermm If desired, an mstruction may 
beplacedinthecodefonowingastrncpyQtoaddatenninationchaiactertotheendofthedeststri^^ Inthecase 
25 where the lengthof src islessthanthatofn,theremainderofdestwinbepaddedv^ THe strcpyQ and 
StmcpyQ functions return a pointer to flie destination string dest . 

Figure 33B fflusliates an example of the results of file stmcpyQ function on string 1452, when stmcpyQ is 
called with the following parameters: 

30 stmcpy(string2, stringl+3, 5); 

where stringZ is character pointer 1454 pointing to the first byte after the terminating character of string 1452, 
stringl+3 is character pointer 1450 incremented by 3 byte^ and 5 is number of character 
. fi,,mthesourcelocationstringl+3tostring2.Aftercopying.theBextchan»cter^^ 
35 stringl m^ be set to the temiinating character (the charact* may have been initialized to the tenninating character 
priortothecopy). lhus.thetwostringsnowoccupy(13 + 6)-19bytesofmemory. If the strcpyQ fimction was 

appUed with character poiiiter 1450 as the source string, the orignml sti^ 

- occupy.(13*2) = 26bytes. • . ' 

Figure 33C iUustrates an efficient method for representing and managing strings in general,.and in small fbotpmit 
40 systems such as embedded systems in particular. String 1452 is stoml izi memory as 12 bytes (no terminating 
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character is required). String structure 1460 includes pointers (Address(A) and Address(L)) to the first and last 
characters of string 1452. Using this string structure, the string's length may be effi^^^ 
the pointer to the first character firota the pointer to the last character. 

Operations such as string copy operations strcpyQ and stmcpyO may also be handled more efficiently. 
With string structures such as those illustrated in Figure 33C, a new string structure 1462 may be created, and the 
first and last character pointers may be initialized to pomt to the re^ Thus, a 

portion or aU the string 1452 does not have to be copied to new storage for the s^ As strings can be hundreds or 
. even thousands of characters long, the memory saved using the string structures and string mediods fanplemented to : 
take advantage ofthem may be considerable. This method of hancUing copies of poitions or aU of a string may te^ 
0 caUed"substringmanagement,"asitdealswiththeeffidenthandlm^ 

Other string fimctions from the standard C string libraiy may be replaced witti string fimcdons takmg 
advantage of the string structure as fllustrated m Figure 33C. Examples of other C string functions include, but are 
not limited to: strstrQ, strcatQ, and sprintOQ. The string handling structures and mediods as described m Figure 33C 
may be used, along widi the hierarchical structure of XML documents, to provide more efBcient handling of XML 
15 text (such as XML messages) in systems with small memory footprints such as embedded systOTs. Tlie following is 
a single example of an XML schema defining a purchase order 

<!I>3CTYPEpurchase.order SYSTEM 
<purchase.order> 
<date>22 May 2000</date> 
20 <billing.address> 

<qaame>John Smitii<yname> 
<street>123 Maiii</street?> 
<city>Anywhere<;^cit>^ 
<state>MA<state> 
25 <2ip>12345-6789<yzip> 
<Vbilling.address> 
<items> 
<iteni> 
<quantity>3</quantit>^ 
30 <productJiumber>248</productnumber> 

<description>DecoiatiYe Widget, Red, Large<ydescripti6tf> 

<unitcost>19.95<unitcost> 
<itera> 
<iteni> 

35 <quantit)^l</quantity> 

<productJiumber> 1 632</productnumbei> 
<description>Battery, AA, 4-pacWdescription> 
<unitcost>4.95</unitcost> 
</item> 

40 <itemtf> 

. </purchase.ordei> 

The hierarchical structure of XML documents may allow them to be processed in a recursive feshion vwdi 
successively smaller portions of the document processed at each level of recursion. References to various portions 
45 are recorded and processed recursively. String structures as described in regard to Figure 33C may be used t 
record die various portions. In tiiis manner, die content of specific XML tags (one line in the above «cample), in 
bne embodiment the smallest unit of die XML document processed recursively, may be. detemiined. efficiently. 
Documents with repeated tags m die same scope may also be handled efficiently, as tags wifliin a given scope may 
be enumerated and processed efficient^. 
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A recursive method for processing an XML document using string structures similar to those described in 
Figure 33C may accept a string structure representing tiie entire XML document string and pointing to the first byte 
and the last byte in the document string. The method may then locate the next subsection of the docunient and pass 
a string structure representing the substring of the entire document string containing the subsection to a processing 

5 fimction for the subsection type. The subsection itself may be broken into another level, of subsections represented 
by string structures passed to processing fimctions for the subsection type. The method may continue in the 
recursive processing of the XML document subsections until the entire document 

Using the strinjg structures with the recursive processing allows the processing to be done without creating 
copies bfthe subsections for processing. Copying of subsections niay be particiilarly costly in recursive processing, 

10 because as the recursion goes deeper, more and more copies of the same data are made. Using the string structures, 
onty tiiie string structure containing the pointers to the first and last bytes in the subsection n^ds to be created and 
passed down to the next level Other operations, such as determimng the length of a subsection, may be performed 
efiBcienfly using , the address information stored in the string stmctures. Also, by \ising the string structures, 
terminating characters such as those used to terminate C strings are not necessary, conserving memory in small 

15 footprint devices such as embedded devices. . 

XML representation of Obiects 

As previously mentioned, Pmi RMI may not be practical for some clients, such as thin clients with miiumal 
memory footprints and mmimal bandwidth. Ihe serialization associated with tiie Jmi RMI is slow, big, requires the 
20 JVM reflection API, and is a Java specific object representation. Java deserialization is also slow, big and requires 
a serialized-object parser. Even Java based thin clients may not be able to accept huge Java objects (along with 
needed classes) being returned (necessarily) across the network to the client, as required in JinL 

A more scalable distributed computing mechanism may be provided by embodiments of a distributed 
computing environment A distributed computing environment may include an API layer for fecilitating distributed 
25 computing. The API layer provides send message and receive message capabilities between cli^ts and swvices. 
This messagmg API may provide an interface for simple messages in a representation data or met^ 
as in the extensible Mark-up Language (XML). Note that while embodiments are described ha»m employing 
XML, otha- meta-data type languages or fonnats may be used in alternate embodiments. In some embodiments, tiie 
API layer may also provide an interface for messages to conununicate betweai objects or to pass objects, such as 
30 Java objects. Objects accessible through API layer 102 are represented by a representation data format, such as 
XML. Thus, an XML representation of an object iiiay be manipulated, as op 

The API layer may sit on top of a messa^g layer. The messaging layer may be based on a representation 
data format, such as XML. In one embodiment, XML messages are generated by tiie messaging l^cr according to 
calls to the API layer. The niessaging l^er may provide defined static messages that may be sent between clients 
35 and services. Messaging layer may also provide for dynamically generated messages. In one embodiment, an 
object, such as a Java object, may be dynamically converted (compiled) into an XML representation. .The object 
may include code and/or data portions. The object's code and/or data portioiis may be compiled into code and data 
segments identified by XML tags in the XML representation. .The messaging layer may then send the XML object 
representation as a message. Conversely, die messaging layer may receive an XML representation of an object The 
40 object m^ then be recoristituted (decompiled) fiom that message. . The reconstitution may examirie the XML 



82 



Wo 01786394 PCT/USOl/15134 

representation for tags identifying code and/or data segments of the XML representation, and use information stored 
in the tags to identify and deconapile tiie code and/or data portions of the object 
Creating and sending an XML representation of an Object 

Figure 34 illustrates a process of moving Java objects between a client 1500 and a service 1502 according 
5 to one embodhnent Service 1502 may be any service supported in the distributed computing environment, 
including space services. Client 1500 employs a gate 1504, which may have been created usmg an XML schema 
received from a sersnce advertisement for service 1502. to communicate vtt^ 

1502. At some point, client 1500 may need.to send Java object 1510 to service 1502. Java object 1510 may 
reference other objects, which may in turn reference otiier objects, and so on. Java object 1510 and its referenced 

10 objects, &e objects they in turn reference, and so on, may be refo^ 

Java object 1510 may be passed to a Java object compilation pmcess 1512 to be con^ 
XML representation ofthe object graph. The XML representation of the object gr^h may be passed as an XML 
data stream 1514 to gate 1504. The XML data stream 1514 may include an XML representation of all the objects m 
the object graph. In one embodhnent, the objects in the object graph may be stored recursivety in the XML data 

15 stream 1514. 

Gate 1504 may then package the XML data stream 1514 in a message 1516 and send the message 1516 to 
gate 1506 of service 1502, Gate 1506 may extract the XML data stream 1514 from XML message 1516 and 
the XML data stream 1514 to an XML data stream decompflation process 1518 to be decompiled to produce the 
object(s) comprising the object graph, including Java object 1510. In one embodiment, the objects in the object 
20 graph may be stored recursively m the XML data stream 1514, and thus a recursive decompilation process may be 
used. 

When service 1502 needs to send a Java object to client 1500, a substantially similar process m^ be used. 
Java object 1520 may be passed to a Java object compilation process 1512 to be compfled to produce an XML 
representation of the object graph. The XML representation of the object graph may be passed as an XML data 
25 stream 1522 to gate 1506. Gate 1 506 may then package the XML data stream 1522 in a message 1524 and send the 
m^age 1524 to gate 1504 of cHent 1500. Gate 1504 may extract the XML data stream 1522 from XML message 
1524 and send the XML data stream 1522 to an XML data stream decompilation process 1518 to be decompfled to 
produce the object(s) comprising the object grsqph, including Java object 1520, 

In another embodhnent, the gates may be responsible for the compUation and d©conq)iIation of Java 
30 . objects. In this embodiment, Java object 1510 may be passed to gate 1504. Gate 1504 may then pass object 1510 
to a Java object compilation process 1512 to be compiled to produce an XML representation ofthe object graph in 
an XML data stream 1514. Gatel504 may Aen package the XML data stream 1514 in a message 1516 and send 
the message 1516 to gate 1506 of service 1502, Gate 1506 may extract the XML data stream 1514 from XML 
message 1516 and send the XML data stream 1514 to an XML data stream decompilation process 1518 to be 
35 decompfled to produce tiie object(s) comprismg the object graph, mcluding Java object 1510. The process of 
sending a Java object from service 1502 to cUent 1500 may be substahtiaUy similar to the process of sending an 
object from the client to the service. 

In one embodiment, object compilation process 1512 and object decompil^on process 1518 may .both 
exist on the client 1500 and ^e service 1502, and may be programmed to perform compUation and decompilation 
40 substantially similarly on the two devices, thus ensuring tiie object(s) output on one end are substantiaUy identical to 
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tiie object(s) input on tiie other end. In one embodiment, XML schemas including descriptions of Java objects may 
be used on both the cUent and/or the service in tiie compilation and decompilation processes, to one embodiment, 
XML schema(s) to be used in the compUation and decompilation of Java objects may be passed by the service to the 
client in the service advertisement 
5 XML provides a language- and platfonn-independent object representation format Thus, the process as 

illustrated in Figure 34 where an object is compiled into an XML representation of the object and decompiled to 
reproduce the object m^ not be limited to moving Java objects, but in some embodnncnts may be appUed to 
movmg objects of other types between entities in a network. 

10 JVMcompilation/decompilationAPi 

Figures 35a and 35b are data flow diagrams iUustrating embodiments i?Aere a 

mcludes extensions for coinpiling objects (e.g. Java Objects) mto XML rqjresentations of die objects, and for 
decompiling XML representations of (Java) objects into (Java) objects. The JVM m^ supply an Applications 
Programming Interfece (API) to die compilation/decompilation extensions. The client 1500 and service 1502 may 
15 be executing within JVMs. The JVMs noay be on the same device or on different devices. 

In both Figure 35a and Figure 35b, the JVM XML compfler/deconq>flar API 1530 m^ accept a Java 
object 1510 as input, and ou^ut XML representation of the object 1510 and all its lefcrenced objects (tiie object 
gr^h of object 1510) in an XML data stream 1514. In addition, the JVMXML compiler/decompiler API 1530 
may accq)t an XML data stream 1522, vMch includes an XML representation of object 1520 and all its referenced 
20 objects (the object graph of object 1520), and output Java object 1520 (and all 

Figure 35a illustrates one embodiment \^ere, when sending Java object 1510, the cUent calls the JVM 
XML compiler/decompiler API 1530. The client 1510 passes Java obje<^ 1510 to die API 1530, which compUes the 
object to produce its XML representation, stores die XML representation ia XML data stream 1514, and outputs 
XML data stream 1514. The cHent may then pass XML data stream 1514 to gate 1504. Gate 1504 may tiien 
25 package the XML data stream 1514 in an XML message 1516 and send message 1516 to service 1502. 

Upon receiving XML message 1524 fix)m service 1502, gate 1522 may extract XML data stream 1522 
from message 1524 and pass data stre^ 1522 to cHent 1500. CUent 1500 may then call die JVM XML 
compiler/decompfler API 1530, passing API 1530 the XML data stream 1522. The API 1530 may then decompDe 
the XML data stream 1522 to produce Java object 1520 and otiier objects in its object graph, returning the objects to 
30. client 1500. 

Figure 35b illustrates another embodiment where, when sending Java object 1510, the JVM XML 
conipiler/decompiler API 1530 is called by the gate. The client 1510 passes Java object 1510 to gate 1504. Gate 
1504 tiien passes object 1510 to API 1530, which conq)iles die object to produce its XML representation, stores die 
XML representatiion in XML data stream 1514, and outputs XML data stream 1514. Gate 1504 ihay then padcage 
35 theXMLdatastreaml514inanXMLmessagel516andsendmessagel516toservicel502. 

Upon receiving XML message 1524 from service 1502, gate 1522 may extract XML data stream 1522 
from message 1524 and pass data stream 1522 to die JVM XML compiler/decompiler API 1530. The API 1530 
may dien decompile die XML data stream 1522 to produce Java object 1520 and other objects in its object graph. 
The gate may then send Java object 1520 and the other objects to client 1500. 
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In one embodiment, the JVM XML compiler and decompfler may be implemented as integrated functions 
of the JVM. In another embodiment, the XML compUer and decompiler may be embodied in API ^ 
iivvocations in standard extensions to the JVM; thus, the core JVM does not have to be modifiei TteJVMmay 
supply the JVM XML compilei/decompUer API 1530 to processes (cUents and/or services) executing within the 
5 JVM to aUow the processes to access the Java object compflation/decompilation fimctionality provided by the JVM. 
In one embodhnent. for a process to utilize the object compilation/decompilation, the JVM within which the process 
U executog must have the r^Ovl XML compilCT/decompUer fimctionality and API 1^^^^ 

Methods using reflection and serialization to tnmsfonn and send objects are typic^ 
appUcations separate from the JVM lUe appUcation must rep««tedly access the JVM to pick apart an object one 
10 field at a time as the transitive closure of the object is dynamically analyzed. Tto tends to be a slow and 
cumbereome process, while also recpiring large amounts of appUcation 

Implementmg the Java object compiladon/decompUation fimctidnaUty wifliin the JVM is advantageous 
because the JVM already miderstands the concept of. and contents o^ an object grj^h. Thus, the 
compilation/decompflation functions may leverage the knowledge (and reuse code) of the JVM in parsing the object 
15 graph to produce the XML representation, and in parsmg the XML representation to produce the object graph. 
Urns, the compiktion/decompilation functions may not have to dupUcate fimctionalily that is provided by the JVM. 
as do object sending methods using reflection and serialization. Uris may allow the code foo^dnt of the 
compilation/decompilation functions to be smaUer than that of object sending methods using reflection and 
serialization. Also, an object may be complied or decompiled by a smgle call to the JVM XML 

20 compiler/decompiler APL 

In addition, integrating the compUation/decompflation of objects with the JVM may aUow the con5)ilation 
and decompilation objects to be perfomied fester than methods using nsflection and seria^^^ 
object traversal model implemented with reflection and serialization, the code outside the JVM does not know the 
structure ox graph of the Java object, and thus must traverse the object graph, pulling it apart, and ultimately must 

25 repeatedly call upoh the JVM to do the compUation (and the reverse process for decompilation). This process may 
be slowed by the necessity of making repeated calls to the JVM. outside the code. Having the compilation and 
decompilation functionality mtegpted with the JVM, as described herein, avoids havmg to make repealed calls firam 
code outside the JVM to the JVM to one embodiment, an object may be complied or decompfled by a single call to 

the JVM XML compiler/decompiler APL 
30 In one embodiment, the compilation/decompilation fimctionality may be hnplemented as a service in the 

distributed computing enviromnent The service may publish a service advertisement in a space. A process m the 
distnT>uted computing enviromnent may use a search or discovery service to locate the compM^^ 
service. Hie process (a client of the service) may then use the service by passmg Java objects to be compiled into 
XML representations and/or XML representations to be decompiled mto Java objects to the service. 
35 Java objects may mclude code (the object's methods) and data. An object's code may be noi>th^ 

code does not change once the object is created. An object's data, however, may be transient Two objects created 
from the same Java class may include identical code, but the data in the two objects may be different In one 
embodiment the compilation fimction mdy compUe a Java object's data mto an XML representation of the object, 
but may not include the object's actual code in the XML representation. In one embodiment infomiation about tiie 
40 object may be inctoded m the compiled XML representation to mdicate to the receiver how to recreate the code for 
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the object nie XML representation may then be stored in an XML data stream and sent (e.g. in.a message) t a 
receiving process (client or service). Hie receiving process may tben pass the XML data stream to the ., 
decompilation fimction. TTie decompilation fimction may. then decompUe the XML data stream to produce the Java 
object including its data. In one embodiment, the code for the object may be reproduced by the decompUation 
function using information about the object inchided in the XML representa^^^ 

. statically defined and the JVM receiving the object may be able to reproduce the code Of necessary) using its 
icnowledge of the object 

In one embodiment, the XML representation of an object produced by the compilation function may 
inchide the Java object's data and information about the Java object TTie infonnationmay inctade class information 
for the Java object An object signature may be included .in the information and may be used to identify the obj«^^ 
class, etc. The decompilation fimction may i«cr«rte the code for the Java object using the mfonnation about the 
Java'object and may decompfle the data fiom &e XML data stream into the Java object Thus, a complete object 
including its code and data may be reproduced on the JVM executing the receiving cU«it or service fi-om the 
decompUed data and the information describing the object In one embodiment, the infomiation describmg the 
object may be stored in one or moi^ XML tags. In one embodiment, the cheat or service rccdving flie XML data 
stream may kclude an XML schema that descn^es the object, and the XML schema may be used to «^ 
Java object fiom the decompiled data and fiom the infiHmation about the Java object The decompibtioa process 
may proceed recursively through the object graph, reconstructing the objects referenced by the object by 
decompilmg the referenced objects' data from the XML data stream and recreating the referenced objects' code 
fiom information about the referenced objects in the XML data stream. 

In one embodiment, the XML representation of the object produced by the compilation fimction may 
include the object's data and mformation that identifies the code of an object In one embodiment, the information 
identifying the codeofthe object may be stored in one or more XML mgsmthe XML data stream, men r^^^ 
the decompilation fimction may recreate the code for Ihe Java object using the iirformation about the «^^^ 
XML data stream and decompUe the data for flie object firom the XML data stream. Thus, a complete object 
including its code and data may be reproduced on the JVM executing the. receiving, client or service from the 
decompaed data and the information describing die code of die object 

Several scenarios of using XML representations of objects to transfer objects between entitira (typicalty 
clients and services) in a distributed computing enviromnent are mcluded for clarification. . These scenarios are 
exemplary and are not intended to be limiting. 

In a first scenario, a service may use the XML compUer/decompfler to compile a Java obj«n hito an XML 
. representation of tiie object and send the XML representation to a cUent The cUent m<qr the use the XML 
compiler/decompiler to decompile tiie XML representation.and perfonn operations on the.data within fte object, 
and hter may use the XML compiler/decompiler to compUe the object mto an XML represent^^^^^ 
retiim ihe XML representation of the object to the service. 

m a second scenario, a service may use the XML compiler/decompiler to compile a Java object mto an 
XML representation of the object and send the XML representation to a client The client m;qr tiien send the XML 
representation to another service,, which may use- the XML compiler/decompiler . to decompU^ die XML 
representation to reproduce the object, perfomi operations on the object at the request of the client (possibly 
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modifying the data), use the XML cdmpiler/decompQer to recompile the modified objea. into its XML 
representation, and send the XML representation of the object to the client 

In a thffd scenario, a service may use the XML compUer/decompiler to compOe a Java object int^^ 

representation of the object and send the XML representation to an object repository or store space. TTie service 
5 may then send a .message to a client informing the client of the location of the XML representation. n»e message 
may taclude a Universal Resource Identifier (URI) for the XML lepresentatioa TTie cUent may then retrieve the 
XML representation ofthe object from the store n)ace, and may use the XML compUCT^^^ 

. representation to reproduce the object Alternatively, the cUent may send the location of the XML representation of 
flie object to another service, along wifli a request for operations to be performed on the object The oflier service 
10 maythenretrievetheXMLrepresentationfiomthestotespace,usethe3a^w^^^ 
XML representation to reproduce the obj ect. and i»iform the requested ope^ 

In a fourth scenario, a process (could be a cUent or service) may locate an object repository OT 

in the distributed computing enviromnent by searching for and findmg a service advertisement for the store space. 
The process may. during execution, create or obtain a plmality of Java objects. TTie process may use the XML 
15 compUer/decompaer to compfle one or more of the objects into XML representations of the objects, and may send, 
as a cMent of &e store space service, the XML representations of the objects to ^e store s^ 

possible later access, or for access by other processes. 

Security issues in the Decompilation of XML Representatidns of Objects 

Spaces, as descnT^ed herein, may serve as a ffle system in the distnT,uted computing envin^ 
20 maybeprovidedforfilesinthesystemintheformofaccessrights. Accessrightsmaybechecked«^^^ 

accessed (opened, read, or mitten to). TTms, a method for providing file access security in the distributed . 
computing enviromnent may be desirable. Ihis method may also be appUed to the XML representations of Java 
objects that may be stored in spaces and transmitted between cUents and services in the distributed computmg 
ehvironmenL 

In one embodiment, a user of a client on a device m the distributed computing enviromnent may be 
identified and authenticated when first accessing the cUent In one embodiment, the user may supply a physical 
identification such as a smart card for identification and au&orization. In another embodiment, a challenge- 
response mechanism (such as user ID and password) may be used for identification ^d authorization. Yet another 
embodiment may use electronic identification such as a digital signatme for identification and fflithorization. Any 
30 other method of identification and authorization may be used. 

Once identified and authorized, the user may then perform various operations on the cUent. includmg 
accessing one or more, services m the distributed computmg enviromnent During these operations, as described 
above, one or more objects may be created Oocally) or acquired fiom elsewhere (e.g. from sem^ 
object^ may be modified and may be compffled into XML representations of the objects and stored locally by the 
35 cUent or sent to a space service for (transitive or persistent) store. Some of the objects may be received fiom 
services (store services or other services) in the fomi of XML representations of the objects, which may be 
decompiled by the XML compilei/deconq)iler to recreate the objecb on the clieiit 

In one embodhnent duriig ti»e decompilation of the XML representation of objects, each XML message 
may be checked to verify that the user has access rights to the obj ect If the user does not have the proper access 
40 rights, the XML compiler/decompiler may not decompUe the object for the user, in one embodiment, a securify 
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exception may be thrown by the XML compUer/decompiler- In one embodhnent, Ihe user may be infonned of the 
access violation. 

Access right information, such as the creator and access levels allowed (creator-only access, read only, 
read^mte. delete, copy, etc.) for the object may be embedded in the XML message(s) containing the XML 
5 representation of the object Access authorization may be determined during the identification and authorization of 
the user. For example, the object may allow "read only" access for most users, and "readAwite" accws for the 
creator of the object If the user tries to access an object using readAvrite access rights, and the user did not create 
the object, the decompilation process may detect this as an access violation, and may disaUow the ^ 

tiieuserJ 

10 In one embodiment, when the user is done using the client, the user may log offor otherwise signal (he user 

is finished with tiie cUent (eg. remove a smart card). Objects created on the cUent by decompilation may be 
automaticdly deleted when the cUent detects tiiat the user is finished. This ms^ P«)h*it Mure users fi«m 
intentionally or accidentaUy accessing the user's objects. In one embodiment, all objects created by decompilation 
may be deleted upon detecting that the user is finished. In anotiier embodiment, a method may be provided to store 

15 at least some ofthe objects created on the cUent persistentiy (e.g. with access rights information), so that the cUent 
m^ later access tiie objects, or provide die objects to ofter users for access. 

In one embodiment, tiie user may have a -^t card" or other physical device to gain access to the clieirt. 
The user may insert the smart card into tiie cKent device to begm tiie session. When flie cKent is finished, die cKent 
may remove tiie smart card, nie client may detect the removal of tiie smart card, and flius detect fliat flie client is 

20 finished, and may tiien proceed to delete objects created by decompilation of XML representations. 

XML-based object repositories 

In tiie distiibuted computing environment, processes (services and/or clients) may desire transient and/or 
persistent storage of objects such as XML schemas. service advertisements, results generated by services, XML 
25 representations of Java objects and/or objects implemented m oflier languages, etc Existing object storage 
technologies tend to be language and/or operating system specific. These storage systems also tend to be too 
compUcated to be used witii small footprint systems sudi as embedded systems. 

JavaSpaces in Jini is an existing object reposhoiy mechanism. A JavaSpace may be only capable of storing 
Java objects and may be too large to be implemented in small devices with Umited amounts of memory. Each object 
30 ma JavaSpace may be serialized as previously described, and tiius has the same Innitationsa^ 

for tiie reflection and serialization techniques: 

A store rnechanism may be provided for tiie distributed computing environment tiiat may be heterogeneous 

(not language or operating system dependent), fliat may scale from small to large devices, and that may provide 
transient or persistent storage of objects. In one embodiment, tiie store mechanism in tiie distiibated computing 
35 enviromnent may be implemented as an hitemet Web page or set of pages defined in tiie XML markup language. 
XML provides a language- and platfbrmt-independent object, representation format enabling Java and non-Java 
software to store and retrieve language-independent objects. Since flie store mechanism is on tiie Web. devices of 
. all types and sizes (small to large) may access tiie store mechanisms. Web browsers may be used to view ttie store 
mechanism implemented as Web pages. Web search engmes may be used to search for contents in tiie store 
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mechanism implemented as Web pages, totemet admin^ 
may be used to administer &e XML-based store mechanisms. 

In one embodiment, the store mechanisms may be used to store objects created, represented or 
encapsulated in XML. Examples of objects that may be stored in the store mechanisms may mchide, but are not 
5 limited to: XML schemas, 30^ representations of objects (for example, Java objects compUed into XML 
representatioiis as described above), service advertisements, and service results (data) encapsulated in XML. In one 
embodiment, to i^event unauthorized access of an XML object, an authorization credential such as a. digital . 
signature or certificate may be included v«th the XML object, and a client wishing to access the XML object may be 
required to have the proper audiorization credential to access the XML object In onie emboduncnt. the store 
10 mechanism may be a space as described in the Spaces section herein. 

Store mechanisms m^ be services in flie distributed compufidg environmeuL A store mediaidsm 
implemented as a service may be referred to as a "store service". A store servke may publish an advertisement in a 
space. The space itself is an example of a store service. Some store services may be transient For example, a 
space service that stores service advertisements may be a transient store. Other store services may be persistent 
15 For example, a store service that stores results from services ni^ be a persistent store. 

Figure 36 iUustrates a cUent 16(M and a service A 1606 accessing store mechanisms 1600 and 1^^^ 

distnT)uted computing enviromnent accoidingto one embodiment Th^ 

is not intended to be limiting to the.scope of this invention. In one embodimeDt. store mechsmisms 1600 and 1602 
may each be an Internet Web page or set of Web pages defined in XML and accessible by a Web brow^^ 

20 Internet tools. Store mechanism 1600 is a transient store capable of storing objects implemented using XML. Store 
mechanism 1602 is a persistent store also capable ofstoring objects nnplemented using XML. Service A 1606 may 
publish an XML service advertisement 1608 in transient store 1600. Persistent store may also publish an XML 
service advertisement in transient store 1600 (or on another transient store in the distributed computing 
environment). At some point, client 1604 may require fimctionality provided by Service A 1606. CUent 1604 may 

25 use a discovery and/or lookup service to locate service advertisement 1608. C3ient 1604 may then construct a 
message gate, as described hereto, and begin communications with Service A 1606. Ghent 1604 may send one or 
more XML request messages to Service A 1606. Service A 1606 may perform one or more fimctions in respom^ 

the one or more request messages. One or more of the fonctions performed by Service A 1606 may produce results 
to be provided to client 1604. 

30 For transient results 1610, Service A 1606 may encapsulate the resuhs in an XML advertisement 1612 and 

publish the advertisement 1612 in transient store 1600 (or on another transient store in the distributed computing 
enviromnent). ServiceA 1606 niay then notify client 1604 that the results 1610 are stored m advertisement 1612 on 
transient store 1600. or client 1604 may be notified by odier mechanisms as described herein. Ghent 1604 may then 
retrieve tnmsient results 1610 from advertisement 1612. Tlie advertisement 1612 may mdude an XML schema 
35 describing the formatting, contents, type. etc. of the transient results 1610. The results miqr be encapsulated in 
XML. Fot example, XML tags may be used to describe portions of the data: 
<XMLtagl> <datal> 
<XMLtag2> <data2> 
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For persistent results 1618, Service A 1606 may use a service or other mechanism as described herein to 
locate XML service advertisement 1616 for persistoit store 1602. and thus locate persisteirt store 1602 for storing 
persistent results. Alternatively, client 1604 may have previously located persistent store 1602 by locating its 
service advertisement 1616, and then may send a Universal Resource Identifier CURI) for a storage location, for 
penistent results 1618 to Service A in an XML message. In one embodiment, persistent results 1618 may be stored 
in an Internet Web page or set of Web pages delSned in XML and accessible by a Web browser. Service. A 1606 
niay theu store persistent results 1618 in persistent store 1602. Service A 1606 may then publish an XML 
advertisement 1616 for the persistent results 1618 in transient store 1600 (or on another transient store m the . 
distributed computing environment) and return flie location of die advertisement 1616 to client 1604. The 
advertisement 1616 may include an XML schema describmg the formatting, contents, type, etc. of the persistent 
results 1618. The results m^ be encapsulated m XML as previously described. The advertisement may also 
mchide the URI of die persistent results 1618. ThecHent 1604 may then retrieve the advertisemrat 1616anduseit 
to locate and retrieve persistent results 1618. Alternatively, Service A 1606 may not publish an advertisement for 
persistent results 1618, but instead may return a URI for the persistent results 1618 to client 1604 so cHent 1604 
may access the results without looking up an advertisement Note in some embodiments, the various advertisements 
shown in transient store 1600 may eadi be stored in different transient st^ 

Thus, store mechanisms m^ be implemented as XMLtesed Internet Web pages m die distributed 
computing environment These store mechanisms may be implemented on a variety of devices in the environment, 
and may provide service advertisements to aUow cUents (which may be other services) to locate and use the store 
0 mechanisms. Existing and future Web and XML tools may be used to manage the store mechan^ The store 
mechanisms may store objects of various ^es implemented or encapsulated m XML. CUents on devices of 
substantiaUy any size, from small footprint devices to siq)ercomputers, m^ access the store mechanisms to store and 
retrieve the various objects on die Internet The cHents may be Java or non-Java applications, as XML provides a 
language-independent storage format Thp transient or persistent object repositories may provide for a file system in 
15 the distributed computing environment and may mclude access checks and other security mechanism as described 
herein. 

Dynamically Converting a Java Object into an XML Document 

In one embodiment, the distributed computing environment may provide a mechanism to conv^ and 
represent an object class instance into an XML document In order to said representation of a class mstance to 
10 anodier service, the object may be converted and represented as an XML document In one embodhnent, v/hea 
receiving an XML document, a program may instantiate a class mstance corresponding to die object represented by 
the document In one embodiment, die objects may be Java objects, and die program may be a Java program. 

In one embodhnent, an intermediary format may be used to represent an XML document and may be 
. dynamically processed to generate a class instance that represents die XML document The class m^ define a set of 
35 instance variables and "set and geT mediods to access die mstance variables. A correspondmg XML document may 
be defined as a set of tags, widi one tag for each instance variable. When die document is parsed, a hashable 
representation may be constructed where die hash key may mclude die mstance variable name and die vahie m^ 
. include die mstauco variable value. If diere are midtiple . occurrences of a complex instance variable, an enumeration 
value may be stored m a hash table. In one embodiment, die process may be limited to only one level of complex 
40 types for die instance variables, and die elements may be homogeneous. 
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In one embodiment a protected instance variable may be added to flie class definidon ftat may include the 
name of the corresponding class. The XML document representation may use the class name as the document type. 
Having the class name embedded m the document may aUow dynamic instantiation of the right class instance when 
tiiie object is reconstructed. 

5 In one embodiment, upon receiving a document, a class instance generator method may be used to extract 

the class type and to parse die document to generate the intennediary hash td)le representation. The generator 
method may instantiate a new class instance and may use the set methods to initialize flie instance objert froin the 
hash table values. In one embodiment, smce the class type is defined and the hash table is generic. Ms process may. 
be performed for any class that matches the above class definition. 

10 iii one embodiment, the iwerse process may also be perfomied ydiere a class instant 

into the mtermediary hash table representation and a genOTtor mefliod may be used to produce an XML documait 
from the hash table representation. Tins process may also be made generic so that ft m^ be perf<^^ 

document that matches the above specification. 

This method is not intended to be limited to Java Class objects, and may be appUed to other computer- 
15 based objects, including class object instances of other programming languages. In addition, tiie m^od is not 
mtended to be limited to XML representations of object instances; other representation formats 
representation languages (such as HTML) may be substituted for XML. 

XML-Based Process Migration 

20 The distributed computing environment may enable the distribution and management of distributed 

appUcations. For example, ftie distributed con]puting environment m^ inctade mobfle clients tiiat are dockable 
with stations fliat provide monitors, printers, keyboards, and various other input/outiput devices that are ^icalty not 
provided on mobile devices such as PDAs, cell phones, etc. TTiese mobile clients may run one or more applications, 
and may migrate from one station to anotiier m tije distributed computing environment Thus, one embodhnent of 

25 tiie distributed computing environment may provide a mefliod for migrating an executing appUcation (process) widi 

its entire current state fiom a mobile client on one node to ttie same mobUe client or anotiier mobile cUoit at anofliei 

node wifliin the distributed computing environment. 

In one embodhnent, an XML representation of die state of a process executing on a cUent or service may be 

created. In one embodiment, tiie XML representation ofttie state offlie process may include a computation state of 
30 tiie device and/or virtual machme on which the process is executing, vdierein tiie computation state of tiie device 
and/or virtual machine comprises information about flie execution state of flie process on tfie device and/or vfrtnal 
machine. A process state may mclude. but is not limited to: flnreads, all objects referenced by tiie flireads. transioit 
variables created during tiie execution of tiie process, objects and flieir data. etc. In one anbodhnen^ data 
describing one or more leases representing grants of access to external services, obtained fiom spaces by tiie 
35 process, wherem tiie one or more external services are external to tiie device and/or virtual machine on which flie 
process is executing, may also be represented in XML and stored witii tiie process state. Leases are described in 
more detail in the Leases section of this document 

Using XML and flie messa^g system as described herein, an XML representation of the state of a process 
' miy be moved from node to node wifliin tiie distributed confuting envfronment. e.g. fiwm node to node, on flie 
40 Internet The XML representation of tiie state of a process may also be stored as an XML object in an Xl^a^^ 
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store medianism as described above, and later retrieved from fte store medianism to resume the process eocecirtion 
onAe same node or on a different liode in the distributed computing environment In one embodiment, the XML 
object compilation/decompiiation process as described herein may be used in creating (compiling) an 3{ML 
representation of the state of . a . process and in regenerating the state of the process by decompiling the XML 
representation of the state of the process. 

. Using tills mechanism, an XML repreisentation of flie state of a process may be stored in an XML-based 
store mechanism, such as a si«ce, from an initid node. Subsequentty, anotiier node may locate tiie stored, state of 
the process, download the state of the process, and resume tiie process fromtiie downloaded stored state at tiie point 
at which it was executing vibea the state was stored. Since tiie process state is stored in an XML format, tiie tools 
and search fecilities described herein to store, locate and retrieve XML objects in XML-based store mechanisms 
may be used to eMble the migration of flie proce^. An advertisement of tiie stored XML representation of the stale 
of die process may be published to aUow a cUent resuming tiie process execution on die same node or anotfier node 
to locate and access the stored sate. 

The XML representation of ttie state , of a process may be stored to an XML-based persistent store 
5 mechanism, and thus may provide a persistent snapshot of ttie process. This may be used as a mcfliod to resume 
process execution on a node afler tiie interruption of tiie process on flie node, for example, due to tiie intentional or 
unintentional shutdown of tiie node. An advertisement of the stored state of flie process may be published to aOow 
clients to locate tiie stored state in flie distributed computing enviromnenL In one embodhnent, to prevent 
unautiiprized access of an XML representation of tiie stored state of aprocess, an autiiorization credential such m a 
10 digital signature or certificate may be inckided wifli tiie stored state, and a client wishing to resume a process from 
tiie stored state may be required to have flie proper autiiorization credential to access the stored state. 

Figure 37 illustrates process migration using an XML representation of tiie state of a process according to 
one embodiment Process A .1636a may be executing on node 1630. Process A 1636a may be a cUent or service. 
At some point during flie execution of Process A 1636a, tiie state of execution of Process A 1636a may be c^itnred 
25 and stored in an XML-encapsnlated state of Process A 1638. Hie execution of Process A. 1636a on node 1630 may 
flicn be stopped. Later, node 1632 may locate tiie XMl^ncapsulated state of Process A 1638 and use it to resume 
Process A 1636b on flie node 1632. jResuming Process A may include using flie stored state 1638 to resume tiiread 
execution, recalculate transient variables, re-establish leased resources, and perfonn any otiier functions necessary to 
resume execution as recorded in flie stored XML state of flie process 1638. 
30 The following is an example of usmg XML-based process migration in flie disbibuted computing 

. environment, and is not intended to be limiting. A mobile client device may be connected to node 1630 and 
executing PrpcMs A 1636a. Tlie user of flie mobile client device may desire to stop execution of Process A 

on node 1630, and to resume execution at a later time at anotfier (or tiie same) node. In one embodiment, tiie user 
may be prompted witii a query to determiiie if flie user wishes to store tiie state of Process A 1636a and resume 

35 execution later. If tiie user repUes in flie afBrmative, tiie XMLnaicapsulated state of the process may be captured 
md stored in persistent store 1634. Later, tiie user may connect flie mobUe confuting device at node 1632. Ja one 
.embodimoit tiie iisermayflien execute process 1636b and select a 'Ttesume from Stor^ TTienode 
• 1632 may flien search for and locate tfie XML-encapsulated state of Process A 1638, download it, and use it to 
resume Process A 1636b. Alternatively! flie process may itself know tiiat it was "suspended" on anotiier node, and 

40 may resume from the stored state witiiout user input . . • - 
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Applications 

Technolo^es exist that allow a user to access network data from remote locations, making the remote data 
appear as local data to the user, provided the user has access to a browser. However, such technologies d not 
provide an automatic infrastructure to query networks near a dientdev^^^ A mechanism for discovering 

information about networks and services near a client device may be desirable. For example, such a mechanism 
may be used to locate information about restaurants, weather, maps, traffic, movie information, etc within a certain 
distance (radius) of the cUent device, and to display desired information on the cUent device. An example of using . 
this mechanism may be a cell phone that can be lised to automatically locate services in a local environment, for 
ex^ple, in a movie theater to display the tides and show times of current features in tiie movie tiieater or in a 
restaurant to view menu selections and prices. In tfie distnT)uted computing enviroiunent as descnl^^ 
mechanism may be used to discover spaces including local information and^or services proxhnate to tbe client 
device. The mechanism may also be applied in other distributed computing environments, for example, the Pmi 
system from Sun Microsystems, Inc. 

In one embodhnent, a mobile client device may include Global Positioning System (GPS) capabili^ and 
wireless conaection technology. Local distributed conqmting networks may be provided. For example, a city may 
provide a citywide distributed computing environment Another example may be a shopping mall wife a local 
distributed computing environment A local distributed computing network may include a discovery mechanism to 
aUow cUent devices to connect to the distributed computing environment and to discover services and data in tire . 
local environment For example, one or more devices in the environment may include wireless cormection 
technology to allow mobUe ctot devices to connect to the network and to access tiie discovery mechanism via tiie 
XML messaging system as described previously. A local distributed computing environment may inchide one or 
more spaces with advertisements for services and/or data to be made available to mobUe clients. For example, a 
citywide distributed computing environment may include spaces that represent entities such as malls, movie tiieaters, 
local news, local weather, traffic, etc. A space may inchide individual service and/or data advertisements for 
accessing services of and information about tiie entity the space represents. The discov^ mechanism may include 
a GPS location or locations of the local distributed computing ravironment, entities represented by space services 
witiiin tiie environment, and/or the various services advertised m fee spaces in the enw^^ 

In one embodiment, wired connections may be provided to a local distributed confuting network. In this 
- environment, a user wife a mobile client device may "plug in" directly to fee network usmg a wired connection 
"docking station". Examples of wired connections include, but are not limited to: Universal Serial Bus (USB), 
FireWire, and twisted-pair Internet In one embodhnent, a dockmg station may also provide mput/output 
capabiHtiessuchasakeyboard,mouse,;anddisplayforfeemobUeclientdevice. In this embodiment, fee location of 
. fee mobile client device may be provided to fee lookup or discovery mechanism by fee docking station. 

hi one embodiment, a mobUe client device may connect to a distributed computing network. As fee user of 
fee mobile cUent device navigates witiiin wheless communications range of fee distributed computing network, tiie 
mobfle client device may constMitiy, or at various intervals, provide a location Vector as input to fee local lookup or 
discovery mechanism. The mobUe cUent device may obtam fee location vector from a GPS system buik into or 
associated with fee mobile client hi one embodhnent. fee cUent may send its location information (e.g. via XML 
ihessaguig) to a local service discovery mechanism, such as one of fee space location mechanisms described herem, 
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For example, the cUent may run the space discovery protocol specifying discovery for spaces offering services 
within a certain range of the cHenf s location, or the cHent may instantiate a space search service to search for spaces 
advertising services provided for the client's vicinity. 

As the mobile client device moves into a specified range of a space within the distributed computirig 
5 environment, the services and/or data stored in the space may be made available to the mobUe client device. In 
embodiments where the cHent device regularly provides its location to a discovery mechanism, local services and/or 
data inay automatically be made available to the client's user. In one embodiment, the user of the mobile cHent 
device m^ determine the specified range of a space. For example, the user may choose to display aU restaurants, 
within one mile of a current location. Alternatively, the range may be specified in the configuration of tiie local 
10 distributed computing network. For example, a cityvwde distnT>uted coraputmg network may be 

provide its services to all users witibin tiiree mUes of the dty limits. La one embodiment, visual indicators, for 
example icons, representing tiie various services and/or data offered by the space may be displ^ed on Hie mobile 
client device. The cUent may then access one or more of the displayed senrices and/or data. In one embodiment, 
information from two or more spaces may be displayed simultaneously on the mobile client device. In one 
15 embodiment, the user may select wbzt services and/or data are to be detected. For example, in a shopping maD, a 
user with a mobile client device may dioose to display all shoe stores in the malL 

In one embodiment, executable code and/or data used in the execution of the code may be downloaded to 
fhc mobile cUent device to allow the user to execute an application provided by a service in the space. For exanq)le, 
moviegoers with mobUe client devices may download interactive movie reviews firom services in a space for the 
20 movie theater, and may thus perform real-time feedback about the movie they are watching. In one embodiment, an 
XML object compilation/decompilation mechanism as described elsewhere herein may be used to compile the code 
and/or data to produce XML representations of the code and/or data, and to decompile fiie XML representations to 
reproduce the code and/or data on the mobHe client device. In one embodiment, an executable version of a process 
may previously exist on the mobile client device, and a stored state of the process may be downloaded to the mobile 
25 client device to aUow the user to execute the process using the stored state. In one embodiment, an executable 
version of a process may previously exist on the mobile cUent device, and data for tiie process may be downloaded 
to tiie mobile client device. For example, data may be downloaded for viewmg with a viewer prog^ 
clientdevice. In one embodiment, an executable version of a process, including the code and data fo^ 
process/may be dowrdoaded for execution on the mobile client device. In one embodiment, the service may execute 
30 the appUcation remotely on behalf of the mobile cUent device, and the service and cU^ 

XML messages including data and optionally XML schemas describing the data. In one embodiment, some code 
may be executed on the service and some on the client For example, the service may execute code to perform 
operations on a set of data such as numerical calculations. The mobile cUent device may execute code that may 
display portions of die data passed to the client firom the service in XML messages and aUow the user of the mobile 
35 cUent device to enter and/or select data and send tire data to the service for performing one or more operations on 
the data. 

In one embodiment, a mobile cUent device may be connected to two or more services in the distributed 
computing network simultaneously. The services may be used independently or m conjunction for performmg a 
series of tasks. For exan^le, one service may be used by a remote client device to locate and/or perform operations 
40 on a set of data, and a second service may be used to print tiie set of data. 
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Figure 38 illustrates a mobile cHent device accessing spaces in a local distributed computing netwoik, 
according to one embodimeiiL A user ofGPS^nabled mobile computing device nOOmaymoveintoprowmity of a 
local distributed computing environment Hie mobile cUent device 1700 may provide its location provided by GPS 
1702 to one or more discoveiy mechanisms 1706 in the local distributed computing network. The discovery 
5 mechanism 1706 may use the provided GPS location of the mobile cUent device and predeteimined locations of 
spaces wthm the environment to determine when the user moves within a specified range of one or more spaces or a 
vicinity served by one or more spaces within the environment For eiampte, discovery mechanism 1706 may 
. determine that mobile client device 1700 has moved within range of space 1704. Discoveiy mechanism 1706 may ; 
then provide one or more advertisements 1710 fiom space 1704 to the niobfle cHent device 1700. Alternatively. 
10 discoveiy mechanism 1706 may provide a Universal Resource Identifier CURI) &r space 1704, or for one or more 
advertisements in space 1704, to mobUe client device 1700. Icons representing the various services advertised by 
service advertisements 1708 and/or data represented by content advertisements 

mobUe cUent device 1700. The user may then select one or more of the advertised services and/or data for 
. execution and/or display on ihe mobile cUent device. The mobile computing device 1700 may establish a wheless 

15 comiection with the device offering the service and communicate widi the device to execute the service usmg the 
Xk4W)ased messaging system as previously described herdn. Alternatively, lie user of the mobfle computmg 
device 1700 may connect flie device at a docking station. Ihe location of the doddng station may have been 
discovered by fee user using the lookup or discovery mechanism 1706. and spaces containing advertisements for the 
dockmg stations to discover the location and avaikbility of docking stations within 

20 Discoveiy mechanism 1706 may ako detect when mobile cUent device 1700 moves mto a selected range of 

space 1714. TTie various service advertisements 1718 and content advertisements 1720 may tfien be made available 
to the user of the mobfle cUent device 1700. When the mobfle client device moves out of the specified range of one 
of the spaces, the advertisements offered by that space may be removed fiom the mobfle client device 1700-s. 
dispUo'. 

25 In one embodiment, advertisements on a space may mclnde location infonnation for the se^^ 

that they provide. TTius, discoveiy mechanism 1706 nnqr delemiine when mobfle client device 1700 moves withm a 
specified range of a particular service advertised on space 1718. and may provide (or remove) die service 
advertisement based upon the location of the mobfle client device 1700. 

Computing devices are shrinkmg whfle at fte same time gMning power and fimctionality. Storage devices. 
30 CPUs. RAM, I/O ASICS, power supplies, etc. have been reduced m size to where small, mobfle client devicM may 
include much of the fimctionality of a fiiU-sized peisonal computer. However, some components of a compute 
system are mrt easfly shrinkable because of the human fector and other fectors. TTiese components include, but are 
not limited to: keyboards, monitors, scanneis. and printeis. Hie limits on reducmg the size of some components 
may prevent mobfle cKent devices from tnily assummg the roie of personal computers. 
35 In one embodhnenti dockmg stations may be provided that aUow users with mobfle client devices to 

comiect to and use components that are not avaflable on the mobfle client device because of hmnan or other fectors. 
. For example, docking stations may be provided m public places sudi as airports or Ubraries. The dockmg stations 
may. provide taoniton!. keyboards, printers or other devices for users with mobfle client devices! In one 
" embodiment, the dockmg stations may not fiiUy fimction without he^ fiom a real computing device such as a mobfle 
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client device connected by a user. The docking station may provide services such as various input/output functions 
to the client iising the coinputing power of the mobile client device. 

A docking station may provide one or more connection optioiis to a mobile client device. The connection 
options may include v/ireless connections and wired connections. Examples of wireless connections include, but are 
5 not limited to: infrared such as IrDA and vrireless network connections similar to those provided by a network 
interface card (NIC) m a notebook computer. Examples of vrared connections include, but are not limited to: USB, 
FireWire, and twisted-pair Ethernet 

A mobile client device may discover the location of docking stations using a method substantially similar to . 
that desCTibed above for mobile client devices. The location of one or more docking stations m a local distributed 
10 computing network may be discovered using a discoveiy mechanism to discover spaces with advertisements for 
docking stations, the mobile client device may provide a location to the discoveiy medianism. In one 
embodiment, the discovery mechanism or a lookup mechanism may return flie location of one or more docking 
stations closest to tiie location of the mobile client device. Alternatively, the discovery medianism or lookiq) 
mechanism may return a URI of the space containing the advertisements for tiie docking stations, and the mobile 
15 client device may then connect with the space to provide the location of the one or more docking stations near the 
device. In one embodiment, the mobile client device may supply information to the lookq> or discovery medianism 
to specify requiiTOients such as monitor resolution, screen size, graphics capabilities, available de>dces such as 
printers and scanners, etc. In one embodiment, information about the one or more docking stations may be supplied 
to the nser on the mobile client device including availability (is another user using the docldng station), components 
20 and capabilities of the various docking stations. 

When a user approaches a docking station, a claiming protocol may be initiated When the docking station 
accepts the claim, secure input and output connections may be established between tiie mobile client device and the 
docking station. Alternatively, the user may select the docking station from one or more docking stations discovered 
using the lookup or discovery mechanism displayed on the mobile client device. When the user selects the docking 
25 station, the claiming protocol may be initiated to give the user secure, exchisive coimection to the docking station 
for the duration of the claim, A docking station release method may also be provided to allow the user to terminate 
the session on the docking station and release tiie docking station for use by other users. In one embodiment, the 
claiming protocol may be a lease on the dodcmg station service as described previously herein. . 

Figure 39a illustrates a user of a mobile device discovering the location of docldng stations according to 
30 . one embodiment Mobile client device 1750 may coimect with discovery mechanism 1756. Mobile client device 
1750 may provide a location obtained using GPS 1752 to discoveiy mechanism 1756. Mobile client device 1750 
may also provide docking station requirements to discovery mechanism 1756. Discovery mechanism 1756 may 
search one or more spaces 1754 for advertisements for docking stations 1758 that meet the requirements of mobile 
client device 1750. In one embodiment, a lookup or discovery mechanism may locate one or more docking stations 
35 within a specified range of mobile device 1750 by comparing location information stored in advertisements 1758 
with the supplied location of mobile device 1750. Discovery mechanism 1756 may then provide the location of one 
or more docking stations within a specified range of mobile cHent device 1750. Alteriiativefy, disc^^ 
1756 may locate a nearest docking station to mobile client device 1750 and provide the tocation to mobfle client 
device 1750, 
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Figure 39b illustrates a mobfle client device 1750 connecting to a docking station 1760, according to one 
embodiment In one embodiment, the user may move mobile client device 1750 into wireless range of docking 
station 1760 and make a wireless connection to the docking station 1760. In another embodiment, the user may 
establish a wired connection to docking station 1760 by connecting one or more cables between docking station 

5 1760 and mobile client device 1750, In one embodiment, the user of the mobile client device 1750 may establish a 
claim to the docking station 1760. The claim may establish secure, exclusive rights to the docking station for the 
duration of the connection. In one embodiment, the claim mechanism may be a lease mechanism for a resource (tiie 
docking station) as described previously herein. In one embodiment, a user may be billed for use of the doddng 
station. For example, the user may supply a credit card number as part of the process of claiming a docking station. 

10 Refer to the description of bill gates in the Mess^e Gates section hereinu Once connected, the user may use the 
various fecilities provided by tiie docking station 1760 such as keyboard, monitor, printer, etc Docking station 
1760 may also include a connection to a local distributed computing network and tibns may provide the user of the 
mobile client device 1750 connected to the docking station 1760 with discovery services for locating service and 
content advertisernents on other devices within the network, allowing the user to locate and use various services and 

15 content in the distributed computing enviroriment as described previously hereirL 

When finished, the user may disconnect the mobile client device 1750 from the docking station 1760. In 
one embodiment, a docking station release mechanism may automatically be initiated when &e mobile client device 
1750 is disconnected from the docking station 1750. The release mechanism m^ clear any claim on fho docking 
station 1760 established by the user of the mobile client device 1750. In one embodiment, the release mechanism 

20 may notify the discovery mechanism 1756 and/or docking station advertisement 1758 that the doddng station is 
available. 

In one embodiment, a user may connect a mobile client device to a docking station without using the 
discovery mechanism. For example, a user in an airport may visually detect a docking station and connect a mobile 
client device to it. Another example may be a library providing a docking station room with a plurality of docking 
25 stations for Tise, where users may access any of the docking stations that are available. 

. Small Footprint and/or Embedded Devices 

Simple embedded or small footprint devices may have limited amounts of memory for storing and 
executing program instructions. A simple embedded device may need to understand a limited set of control inputs 
30 for initiating fimctionaUty of die device and outputs for reporting the status of the device. An exanq)le of a simple 
embedded device is a "smarf' switch (such as a ligjit switch) with embedded circuitry for controlling the switch and 
thus the device controlled by the switch. The smart switch may only need to imderstand two control requests 
(change the state of the device, request the state of the device) and to send one status message (the state of the 
device). The smart switch may mariage the device to \^ch it is connected by receiving its control requests from 
35 one or more control systems and reporting status messages to the one or more control systems. 

In one embodiment, tiie distributed computing environment may provide a framework (protocol) for 
including small devices tiiat may not have the resource foo^rint (such as memory) necessary to iinplement the ftJl 
protocol of the distributed conq)uting enviroEunenL In one embodiment, an agent ;nay be provided as a bridge 
between the small device-capable protocol and the full protocol The agent may perform the ftiU protocol discovery 
40 for the small device, so the device may not be required to implemjent the full discovery protocol and service 
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activation. In one embodiment, the small device may only need to send service-specific messages. In one 
embodiment, these messages may be preWed on the smaU device, so the small device may only have to send 
messages that are part of the service activation to the agent TTie agent may perfonn the service activation via the full , 
protocol to the service and forward incoming message fiom the device to the. service. and/or may forward repli«! 
5 . fromtheservicetotheclienL Thus,theagentmayactasaserviceconnectorforthesmallclient. 

In one embodiment of the distributed computing enviromnent, an embedded device may be configured to 
receive a specific set of control requests in the form of XML messages and to send a specific set of XML messages 
to make requests, report status, etc. In one embodiment, a control system may be configured to manage a variety of 
devices by sending XML request messages specific to each device or category of device that it controls and by . 
10 receiving XML messages fiom &e devices. In one embodiment, one or more XML schenws may be used to define 
an embedded device's specific set of XML messages; the schema may be used by Ibe embedded device and/or the 
control system in sending and receiving XML messages. 

An embedded device may inchide a "thin" implementation of the XML messaging system as previously 
described herein that supports the specific se^ of messages for controlling and monitoring the simple embedded 
15 device. TTie implementation of the XML messaging system may be taiW for use xvith small footprint; simple 
embedded devices, and thus may fit m the limited memory of the smaU footprint d m one embodiment, the 

XML messaging system may be implemented in a small footprint wilh a virtual machme targeted at small footprint 
embedded devices (e.g. KVM). A networking stack (to support the transport protocol for communications with one 
or more control systems) may be associated with the virtual machine and the XML messaging layer msQ^ ^^^^ 
20 of the networking stack. It is noted that this implementation of the messaging system may be used in other devices 
than small footprint or embedded devices. 

In one embodiment, static or pre-generated messages may be used for requests from control systems to 
embedded devices. TTie static messages may be precompUed and stored in the embedded devices. An incoming 
message may be compared with the stored static messages to find a match for the message and thus to perfonn the 
25 function requested by the message, thus reducmg or eliminating the need for code to parse incoming messages. 
Outgoing messages may be read directiy from the stored static messages, thm reducing 

dynamicaUy compile outgoing messages. TTms. static messages may be used to reduce the code footprint of the 
. messaging layer in embedded systems; For example, static Java objects (Java op codes) may be used for request.and 

status messages. 

30 Figure 40a illustrates an embodiment of embedded devices 1804a and 1804b controUed by a control system 

1800. accordmg to one embodhnent Control system 1800 may be networked with the devices 1804a and 1804b it 
contii)ls in any of a variety of ways, m network 1810 may bewed(Etheniet. coaxial,^^^ 
etc.) and/of wireless (IrDA, microwave, etc.). In one embodiment, embedded 

a thin implementation of the XML messaging system for communicating with control system 1800 over network 
35 . 1810. Con1rolsysteml800mayhaveanhnplementationoftheXMLmessagingsystemforsendingrequeststo 

receivmg responses from embedded devices 1804a and 1804b. In one embodiment, control system .1800 may 
include software and hardware configm^d to present an inteifece to allow a user to display the status of and 
remotely- control the embedded devices 1804a and i804b. In one embodiment, control system 1800 m^ inckde 
software and/or hardware for automatic control of embedded devices 1804a and 1804b. 



98 



wo 01/86394 



PCT/USOl/15134 



In one embodiment, embedded devices 1804a and 1804b may be part of another environment The 
devices may not support the. message passing model implemented by the distributed network environment For 
example, tiie devices may be nodes in a networked automation and control system such as a LonWpiics network. 
Control system 1800 may include a control system hardware and/or software for controUbg devices in the other 
environment Control system 1800 may serve as a bridge between the distributed computing environment and the 
other environment The distributed computing environment may also provide a method or methods to wrap existing 
device discovery protocols for discovering the devices for access from the distributed network environment 
Bridgnig and wrapping protocok are fiulher described herein in the Brid^ 

Control system 1800 m^ be connected remotely or locally to one or more other systems in ftie distributed 
computing environment Figmre 40a shows control system 1800 connected to client 1806 via tiie Internet 180i 
Client 1806 indirectly request the status o^ and send control requests to, embedded devices 1804a and 1804b 
throu^ control system 1800. Thus, control system 1800 may serve as a proxy or bridge fi>r embedded devices 
1804a and 1804b, See the Brid^g section herem. To enable sophisticated communicationbetween the elicit 1806 
and the control system 1800, the client and the control system may have different in^jlementations of the XML 
messaging system than the thin implementation on the embedded devices 1804a and 1804b. In one embodiment, 
client 1806 may include software and hardware configured to present an interfece to allow a user of client 1806 to 
display Ae status of and remotely control tiie embedded devices 1804a and 1804b. In one embodiment, chent 1806 
must present the correct authorization credentials to control system 1800 to enable the client 1806 to access 
embedded devices 1804a and 1804b. In one embodhnent, client 1806 may be granted access at different levels. For 
example, chent 1806 may only be able to view the status of embedded devices 1804a and 1804b but not be allowed 
to remotely control the devices, hi one embodiment, control system 1800 may be a service, m^ have a service 
advertisement published in the distributed computing environment, and tiius may be accessed by client 1806 using 
the client-service method as described previously in this document In one embodiment, client 1806 may be able to 
view the status o^ and to remotely control, control system 1 800. 

Figure 40b illustrates client control syston 1808 connected via the Internet 1802 to embedded devices 
1804c and 1804d, according to one embodiment In one embodinaent, embedded devices 1804c and 18044 may 
include a thin implementation of the XML messagmg system for communicating with client control system 1808 
over tiie Internet 1802. Client control system 1 808 may have an implementation of the XML messagmg system for 
sending requests to and receiving responses from embedded devices 1804c and lS04d In one embodiment, client 
control system 1808 may iiiclude software and hardware configured to present an interfece to allow a user to display 
flie status of and remotely control the embedded devices 1804c and 1804d: In one embodhnent, cUent control 
system 1800 may include software and/or hardware for, automatic control of embedded devices 1804c and 1804d. 

A difference betweeii Figure 40a and Figure 40b is tha^ iu the embodiment iUustrated in Figure 40b, .the 
embedded devices 1804c and .1804d m^ be accessed by one or more clients in the distributed computing 
environment without requiring a proxy (e.g. control system). Embedded devices 1804c and 1804d may inchide 
services for accessing the functionality of the devices, may have published service advertisements m the distributed 
computing environment, and thus may be accessed via the client-service method as described previously m this 
document 

The distributed computing environment may include a mechanism for a resource-limited client to retrieve 
Universal Resource Identifier (URI) addressed resources. For exari^le, a client tiiat is only capable of sendmg and 
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receiving messages via an IrDA connection may not be able to establish a URI connection to retrieve results from a 
results space. In one embodiment, a service may be provided as a bridge between the client and the URI resource,. 
The bridge service may mteract with the client via XML messages to gather input parameters. The following is 
mchided as an example of XML input message syntax and is not intended to be limiting m any way: 

<type name=*lIttpGet^ 

<element name="urlstring" type="str!ng"/> 

</type> 

Then, outside the distributed computing environment, the bridge service may establish a URI connection 
and retrieve the resource. The resource may then be (encapsulated as a p^load in.one or more XML messages and 
sent to tiie cHent by the bridge service. 

The following iUustration of one possible use of embedded devices wiflithin m^lementalions of the XML 
messa^g system is mcluded for exemplary purposes and is not mtended to be limiting . A building m^ mclnde a 
pluraUty of electronic devices that consume energy (e.g. Ughts, air conditioners, oftice equipment), and thus may 
require a system for maintaming an optimum energy consumption level The plurality of devices may each include 
an embedded device for controlling the electronic devices. The embedded devices may mclude the ihin 
inq>lementation of the XML messaging system. One or more control systems may be coupled to the devices in a 
network, for example, a building LAN or even the Internet A control system m^ store and execute a bufldmg 
management software package and an implementation of the XML messa^g system configured to be used by the 
software package for monitoring and controlling the devices. The control system may accept ii^ut from users, and 
may display and otiierwise ou^ut status mformation for the building energy consumption system, including status 
mformation for each of the plurality of devices. Energy consumption may be monitored by receiving XML status 
messages from each of the plurality of devices. When energy consumption levels need to be adjusted, XML control 
messages may be sent to one or more of the devices to cause the energy consumption to change. 

Implementing Services 

In one embodunent, tiie distributed computing environment may provide a mechanism for unplementmg 
services as servlets. The mechanism m^ provide functionafity for developing services for the distributed 
computing environment 

In one embodiment, an Application. Programming Interfece (API) may be provided tiiat provides, the 
functionality to allow the service to be initialized and registered in a space. In one embodiment, the API m^ 
be used to invoke the mitialization of the service and to generate an initialization status page, for example, an 
HTML page, that may define tiie status of the service. A user may access the status of the service by accessing the 
status page from a browser. In one embodiment, the API may be used to process incoming messages and to 

generate documents in response to the messages. 

An embodiment of the servlet mechanism may provide several fimctions including, but not limited to: 

• . Management ofthe client connection to the service (unique session ID) 

• Management of an activation space that may be used to store results advertisements 

• Management of leases on connections sessions and results m activation spaces 

• Garbage collection of sessions and results 
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• Authentication of clients 

• Generation of client capabilities on a per session basis 

In one embodiment, the distributed computing environment may provide a service cascading mechanism by v^^ch. 
new, complex services may be constructed from other existing services. For example, from a JPEG-to-PostScript 
5 transformation service and a print service, combining the transformation and print service may create a third 
cascaded service. In one embodiment, two or more services may be combined into a complex service by defining 
access methods ofthe two or more services as the access methods ofthe cascaded service. The following service 
. advertisement for a cascaded service is inchided for exemplary purposes 
and is not intended to be limiting in any way: 

10 

<Service> 
<name>Complac Servicednam^ 
<ID>...</ID> 

<descriptiori> </descriptioEt> 
15 <AccessMethod> 
<;AccessMethod> 

<namei>com-transcode. jpg2psdname> 

<implementation>http'7/www.transcode.com/softwareflpg2ps.jardimple^^ 
20 </AccessMethod> 
<AccessMethoc> 

<name>com.printerilpPrint</name> 

<implementation>htlp-7/www.printerxoni/software/ftppri^^ 
25 </AccessMediod> 
<yAccessMethod> 

. <yService> 
Conclusion 

30 Various embodiments may further include receiving, sending or storing instructions and/or data 

implemented in accordance with ±e foregoing description upon a carrier medium. GeneraUy speaking, a carrier 
medium may include storage media or memory media such as magnetic or optical media, e.g., disk or CD-ROM, 
volatile or non-volatile media such as RAM (e.g. SDRAM, RDRAM, SRAM, etc.), ROM. etc. as weD as 
transmission media or signals such as electricd, electnimagnetic, or di^^ 

35 medium such as network and/or a wireless link. 

Various modifications and changes may be made as would be obvious to a person skilled in the ait having 
the benefit of this disclosure. It is intended that tiie invention embraces all such modifications and changes and, 
accordingly, the specifications, appendices and drawings are to be regarded in an illustrative rather than a restrictive 
- sense. . 



101 



wo 01/86394 



PCT/USOl/15134 



10 



WHAT IS CLAIMED IS: 

1. A method for a(xessing a service in a distnljuted compute 
a cUent locating a first service within the distribu 

the Ghent requesting a capabiUty credential to aUow. the cUent access to a portion of the first service's 
^ capabilities, wherein said requesting a capability credential covaprises the cUent indicating a set of 

desired capabihties; 
. the client receiving said capabiUty credential, wherem said capa^^ 

the right to use said portion of the first service's capabilities; and 
the cUent using said capabihty agential to access one or more of said 

capabilities. 



•me method as recited in claim 1. wherein said requesting a capability credential comprises the client 
ading a capabiUty credential request message, wherein said capability credential request message comprises an 
15 identification of said first service and an indication ofthe set of desired capabilities. 



2. 

send 



3. ilKs method as recited in claim 2, wherein said identification of said first serv^ 
Unique Identifier (UUID). 

20 . 4. The method as recited in claim 2, wherein said capability credent^ request message if formatted in 
extensible Markup Language (XML). 

5. The method as recited in claim 2, finttier comprising: 

the cHent receiving an advertisement for the first service, wherein said advertisement desc^ 

25 of the first service's capabilities; and 

wherein said mdication of the set of desired capabiUties comprises an indication of said adverts 

6. The method as recited m claim 5, wherein said indication of said advertisement is said advertisement itself 

30 7. TTiemefliod as recited in claim 5, wherein said indication of said advertisement is a Unifi)miR^onrce 
Identifier (URT) to sdd advratisement 

: 8. lie metiiod as recited in claim 5, wherein said advertisement describes all of the first service's capabilities. 
. and wherem said mdication of said advertisement in said capability credential request message m a version of said 
35 advertisement edited to describe only said set of desired capabilities. 

9. The method as recited in claim 5, wherein said advertisement is a protected advertisement that describes 
the first service's capabilities but does not provide ap interfece to the first service's c^^ 

40 
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10. The method as recited m claim 1, further comprising: 

the client receiving a protected advertisement for the first service, wherein said protected advertisement 

indicates an address for sendmg said capability credential request message to; and 
wherein said requesting a capability credential comprises the chent sen(Hng a capability credential request 
' message to said address indicated in said protected advertisement 

11. The method as recited in claim 1 0, wherein said address indicated in said protected advertisement is for an 
authentication service, wherein said sending a capability credential request message comprises sending said 
capability credential request message to said authentication service, the method further coii^>rising the 
authentication service sending a credential request response message to the client in response to said capability 
credential request message. 

12. The method as recited in claim 11, wherein said credential request response message includes said 
capability credential, wherein said receiving said capability credential comprises receivmg said c^>ability credential 
fiom said authentication service in said credential request response message. 

13. The method as recited in claim Ijfiirther comprising: 

tiie client receiving a protected iadvertisement for the first service, wherein said protected advertisement 

indicates an authentication service; and 
wherem said requesting a capability credential comprises tiie client requesting a capability credential from 

said authentication service, 

14. The method as recited in claim 13, the method fiirther comprising: 

said authentication service determinmg a level of the first service's capabilities that the client is authorized 
to use; 

said authentication service generating said capability credential according to said level and said set of 
desired capabilities; and 

said authentication service sending said capability credential to the client, wherem said portion of the first 
service's capabilities that said capability credential indicates that the client has a right to use is no 
more than said set of desired capabilities. 

15. The method as recited in claini 14, wherein said portion of the first service's capabilities that said 
cq)ability credential mdicates that the client has a right to use is the lesser of said level of the first service's 
capabilities that the client is authorized to use and said set of desired capabilities. 

16. The method as recited in claim 1, wherein said using sdd capability credential to access one or more of 
said portion of tiie first services capabilities comprises the client sending a message to die first service to access a 
first c£^)ability, wherein the message includes said capability credential, die mediod finther comprismg the first 
s^ice authenticating said capability credential received in the message to verify that the client has tiie ri^ to use 
said first capability. 
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17. A client device, comprising: 

a connection to a distributed computing enviromnent; 

an interface coupled to said connection and configured to locate a first service within the distributed 
computing environment; 

5 wherein the interfece is further configured to request over the connection a capability credential for a set of 

desired capabilities to allow tiie client on the client device access to a portion of the first service's 
capabilities; 

wherein the interface is further configured to receive over the connection said capability credential, wherein 
said capability credential mdicates that the client has the right to use said portion of the first 
10 service's capabilities; and 

vdierein the interfece is further configured to use said capability credential to access one or more of said 
portion of the first service's cz^abilities. 

18. The client device as recited in claim 17, wherem the mterfece is configured to request a capability 
15 credential by sending a capabiHty credential request message, wherein said capability credwitial request message 

comprises and identification of said first service and an indication of the set of desired capabilities. 

19. The client device as recited in claim 18, wherein said identification of said first service comprises a 
Universal Unique Identifier (UUID). 

20 

20. Hie client device as recited in clann 18, wherein said c^ability credential request message if formed in 
. extensible Mariaip I^guage (XML). 

21. The client device as recited in claim 18, v**ierein the interfece is further configured to receive an 
25 advertisement for the first service, wherein said advertisement desoibes the portion of the first service's capabilities, 

and wherein said mdication of the set of desired capabilities comprises an indication of said advertisement 

22. Tbe client device as recited m claim 21, wherein said mdication of siaid advertisement is said advertisement 
itself. 

30 

23. Hie client device as recited in claim 22, wherein said indication of said advertisement is a Uniform 
Resource Identifier (URI) to said advertisement 

24. The client device as recited in claim 21, wherein said advertisement describes all of the first service's 
35 capabilities, and wherein said indication of said advertisement in said capability credential request message m a 

version of said advertisement edited to describe only said set of desired capabilities. 

25. Hie client device as recited in claim 21, ^^erein said advertisement is a protected advertisement that 
d^cribes the first service's capabilities but does not provide an interface to the first service's capabilities. 

40 
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26. The cUeat device as recited in claim 17, wherein tiie interfece is further configured to receive a protected 
advertisement for the first, service, wherein said protected advertisement indicates an address for sending said 
capability credential request message.to, and wherein the interfece is configured to request a c^abQity credential by 
sending a capability credential request message to said address indicated in said protected advertisement 

.27. The client device as recited in claim 26, wherein said address indicated in said protected advertisement is 
for an authentication service, herein said sendmg a capability credential request message comprises sending said 
capabflity credential request message to said authentication service. 

2S: The client device as recited in claiin 27, w^iercin the interfetce is configured to receive, said c^jability 
credential fit)m said authentication service in a credential request response message. 



29. The client device as recited in claim 17, wherein tiie interface is fiirdierconfig^ 

receive a protected advertisement for tiie first service, wherem said protected advertisement indicates an 
15 authentication service; and 

request a capability credential by requesting a capabiHty credential 

30. The cHent device as recited in claim 29, wherem said portion of the first service's capabflities that said 
capability credential indicates that the cHent has a ri^t to use is the lesser of said level of the first service's 

20 capabifitiestiiat file client is authorized to use and said set of desired capabi^ 

31. The client device as recited in claim 17, wherem the interface is configured to use said capability credential 
to access one or more of said portion of the first services capabihties for said cUent by sending a message to tiie first 
service to access a first capability, wherein the message includes said capability credential so that the first service 

25 may authenticate said capability credential received in the message to verify that the client has the right to use said 
first c^ability. 

32. Hie cHent device as recited in claim 1?, wherein said interfece comprises one or more processes executable, 
on a processor within the client device. 

30 • 

33. A. carrier medium comprismg program instructions, wherem tiie program kistructions are computer- 
executable on a client device to implement; 

locating a first service witiiin the distributed computmg envhx^ 

requesting a capability credential to allow a client on the cHcnt device access to a poition of the first 
35 service's capabilities, vt^erein said requesting a capability credential comprises tiie client 

indicating a set of desired capabilities; 
receiving said capability credential, wherein said capability credential indicates that the client has the right 

to use said portion of the first service's capabilities and . . 
usmg sdd capability credential to access one or more of said portion of the first s^ 

40 
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. 34. nie earner medium as recited in claim.33, ^vherem said requesting a capabiUty credential comprises the 
client sending a capabiUty credential recpiest message, wherein said capability credential request message comjMises . 
an identification of said first service and an indication of tiie set of desired capabilities. 

5 35. The carrier medium as reched in claim 34, wherein said identification of said first service comprises a 
. UnivCTsalUnique Identifier (UUID). 

36. The earner medium as recited in claim 34, wherein said capabiUty credential request message . 
in extensible Markup Language (XML). 

10 . 

37. TTie carrier meditmi as recited in claim 34, wherein the program instroctions are 

the client device to fiirtijer nnplement 

receiving an advertisement for the first service, wherein said advertisement desciiT^ 

■ service's capabilities; and 

15 wherein said indication ofihe set ofdesiredcapabiUties comprises an indication of said adverti^ 

38. Hie carrier medium as recited in clahn 37, wherein said indication of said advertisement is said 

advertisement itsel£ 

20 39. Hie earner medium as recited in clahn 37. wherein said indication of said advertisement is a Uniform 
Resource Identifier (URI) to said advertisement 

40. Tie carrier medium as recited in claim 37. wherein said .advertisement descnljesaU of the ^ 
capabiHties. and wherein said indication of said advertisement in said capability credential request message hx a 
25 version ofsaid advertisement edited to describe only said set of desired capabilities. 

4L Tie carrier medium as recited m claim 37, wherein said advertisement is a protected adverti^ 
descnTjes the fin* service's cap*iMes but does not provide an mterfece to tiie first serv^ 

30 . 42. Hie carrier medium as recited m claim 33, wherein the program instructions are computer-executable on 

the client device to fiirther implement 

receiviig a protected advertisement for the first service, wherem said protected advertisement m^^^ 

address for sending said capability credential request message to; and 
. wherein sad requesting a capability credential comprises tiie cUent sending a capability credential request 
35 message to said address indicated in said protected advertisement 

43. nie carrier medium as recited in claim 42. wherein said address indicated in said, protected advertisement 
is for an authentication service, wherein said sending a .capability credential 
c^ability credential request message to said authentication service. 

40 
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44. The cairier medium as recited in claim 43, \\4ierein said receiving said capability credential conqnises 
receiving said capability credential from said authentication service in a credential request response message. 

45. Tiie carrier medium as recited in claim 33, vrfierein the program instractions are computer-executable on 
5 tiie client device to further implement 

receiving a protected advertisement for die first service, wherein said protected advertisement indicates an 
authentication service; and 

wherein said requesting a capability credentid comprises the client requesting a capability credential from 
said authentication service. 

10 

46. The cairier medium as recited in dahn 45, M^m said portion of 1^ 

capability credential indicates tiiat iiie cliait has a right to use is the lesser of smd level of the first s«vice's 
capabilities that the client is authorized to use and said set of desired cq)abilities. 

15 47. The cairier medium as recited in claim 33, wherein said usmg said capability credaitial to access one or 
more of said portion of the first services capabilities conqaises Ae chent sendmg a message to the first service to 
acicess a first capability, wherein the message mcludes said capability credential so that the first service may 
authenticate said capability credential received in the message iovcnfy ttiat the client has the right to use said first 
capability. 
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